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

On Thursday, June 21, 2001 05:08:13 PM +0200 Andrea Arcangeli
<> wrote:

> It seems we can more simply drop the tmp->b_end_io == end_buffer_io_async
> check enterely and safely. Possibly we could build a debugging logic to
> make sure nobody ever lock down a buffer mapped on a pagecache that is
> under async I/O (which in realty is "sync" I/O, you know the async/sync
> names of the kernel io callbacks are the opposite of realty ;).
> The reason it seems safe to me is that when a pagecache is under async
> I/O (async in kernel terms) it says locked all the time until the last
> call of the async I/O callback, and _nobody_ is ever allowed to mess
> with the anon bh overlapped on the pagecache while the page stays locked
> down. As far as the async end_io callback is recalled it means the page
> is still locked down so we know if the end_io callback points to
> something else it's because of a underlying remapper, nobody else would
> be allowed to play the bh of a page locked down.

Think of a mixture of fsync_inode_buffers and async i/o on page. Since
fsync_inode_buffers uses ll_rw_block, if that end_io handler is the last to
run the page never gets unlocked.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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