Messages in this thread | | | Date | Wed, 31 Dec 2003 01:59:13 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch |
| |
Suparna Bhattacharya <suparna@in.ibm.com> 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?
Which is desired behaviour for fsync(), but perhaps not suitable when this code is reused for the O_DIRECT pagecache synchronisation function.
- 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/
| |