Re: [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch

[Suparna Bhattacharya]

On Wed, Dec 31, 2003 at 01:59:13AM -0800, Andrew Morton wrote:
> Suparna Bhattacharya <suparna@xxxxxxxxxx> wrote:
> >
> > > If you are referring to this code in mpage_writepage():
> >  > 
> >  > 		lock_page(page);
> >  > 
> >  > 		if (wbc->sync_mode != WB_SYNC_NONE)
> >  > 			wait_on_page_writeback(page);
> >  > 
> >  > 		if (page->mapping == mapping && !PageWriteback(page) &&
> >  > 					test_clear_page_dirty(page)) {
> >  > 
> >  > 
> >  > then I don't see the race - the page lock synchronises the two threads?
> >  > 
> > 
> >  But filemap_fdatawait does not look at the page lock. So there's a
> >  tiny window when the page is on locked_pages with PG_dirty cleared
> >  and PG_writeback not set.
> 
> OK, but the thread which is running fdatawrite/fdatawait isn't interested
> in that page, because it must have been dirtied _after_ this thread has
> passed through filemap_fdatawrite(), yes?

Not exactly. The page could actually have been dirtied _before_ this 
thread passes through filemap_datawrite, but is just being parallely 
written back by a background thread.

Regards
Suparna

> 
> Which is desired behaviour for fsync(), but perhaps not suitable when this
> code is reused for the O_DIRECT pagecache synchronisation function.
> 

-- 
Suparna Bhattacharya (suparna@xxxxxxxxxx)
Linux Technology Center
IBM Software Lab, India

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