Re: correction: fs/buffer.c underlocking async pages

Chris Mason (mason@suse.com)
Thu, 21 Jun 2001 11:16:42 -0400


On Thursday, June 21, 2001 05:08:13 PM +0200 Andrea Arcangeli
<andrea@suse.de> 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.

-chris

-
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/