lkml.org 
[lkml]   [2001]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: correction: fs/buffer.c underlocking async pages

On Thu, 21 Jun 2001, Andrea Arcangeli wrote:
>
> It seems we can more simply drop the tmp->b_end_io == end_buffer_io_async
> check enterely and safely.

I doubt it.

Think about somebody who writes a partial page (but a full buffer).
Somebody _else_ then reads the rest of the page. You'll have one buffer
up-to-date (but possibly under write-back IO), and the others being read
in asynchronously.

> +++ 2.4.6pre5aa1/fs/buffer.c Thu Jun 21 17:05:18 2001
> @@ -850,7 +850,7 @@
> atomic_dec(&bh->b_count);
> tmp = bh->b_this_page;
> while (tmp != bh) {
> - if (tmp->b_end_io == end_buffer_io_async && buffer_locked(tmp))
> + if (buffer_locked(tmp))
> goto still_busy;
> tmp = tmp->b_this_page;
> }
>
> can anybody see a problem in the above patch? Al, Ingo, Linus?

The above _will_ break. "tmp" may be locked due to the write - and the
write will never call "end_buffer_io_async" because writes do not unlock
the page. So if the write finishes last, you'll _never_ unlock the page.

I don't see why Stefan wants to change the current logic. The current
logic is correct, and if there are double-unlock problems then those are
due to some other bug.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.125 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site