Well, that would leave the page dirty (including in the page tables) if it
was under page writeback when the MS_ASYNC happened.
So I agree, we shouldn't necessarily wait, but if we want the page tables
to be cleaned, right now we need to.
It would require fairly invasive changes. Right now the actual page
writeback does effectively:
...
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
if (PageWriteback(page) ||
!clear_page_dirty_for_io(page)) {
unlock_page(page);
continue;
}
ret = (*writepage)(page, wbc, data);
...
and that "clear_page_dirty_for_io()" really does clear *all* the dirty
bits, so we absolutely must start writepage() when we have done that. And
that, in turn, requires that we're not already under writeback.
Is it possible to fix? Sure. We'd have to split up
clear_page_dirty_for_io() to do it, and do the
if (mapping && mapping_cap_account_dirty(mapping))
..
part first (before the PageWriteback() tests), and then doing the
if (TestClearPageDirty(page))
...
parts later (after checking that that we're not under page-writeback).
So it's not horribly hard, but it's kind of a separate issue right now.
And while the *generic* page-writeback is easy enough to fix, I worry
about low-level filesystems that have their own "writepages()"
implementation. They could easily get that wrong.
So right now it seems that waiting for writeback to finish is the right
and safe thing to do (and even so, I'm not actually willing to commit my
suggested patch in 2.6.24, I think this needs more thinking about)
Linus
--
