Messages in this thread | | | Date | Wed, 31 Dec 2003 01:35:21 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch |
| |
Suparna Bhattacharya <suparna@in.ibm.com> wrote: > > It seems like the case Daniel is thinking about is when > a process has issued writes to the page cache, and then filemap_fdatawrite > is called, while these pages are being written back to disk parallely by > another thread (not holding i_sem). The filemap_fdatawrite wouldn't see > pages that are in the process of being written out by the background > thread so it doesn't mark them for writeback.
If those pages are under writeout then they are clean and filemap_fdatawrite() has nothing to do.
If, however, those pages were redirtied while under I/O then they are dirty, on dirty_pages and are under writeout. In that case filemap_fdatawrite() must wait for the current write to complete and must start a new write.
> The following filemap_fdatawait > would find these pages on the locked_pages list all right, but if its > unlucky enough to be in the window that Daniel mentions where PG_dirty > is cleared but PG_writeback hasn't yet been set, then the page would > have move to the clean list without waiting for the actual writeout > to complete !
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?
- 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/
| |