On Fri, 25 May 2007 00:08:43 +0100 David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote: > > > hm. I don't see why that race window would be a problem in practice: the > > page-exciser does a lock_page();wait_on_page_writeback() as normal, then > > proceeds with its business? > > No. The page-exciser ends (cancels) PG_writeback, not waits for it (something > has to clear the flag). The problem is that the truncation routines may be > sat there holding a lock on the page whilst waiting for PG_writeback to go > away - so we have to clear PG_writeback before we can think about getting > PG_lock:-( But we already covered that? Your exciser can do an unconditional end_page_writeback(), because it is this thread of control which did the set_page_writeback(). So we end up with: end_page_writeback(page); lock_page(page); wait_on_page_writeback(page); <now nail it> > > But given that this doesn't work right for some reason, can we use PG_error > > and then handle that appropriately in the filesystem's ->prepare_write() and > > ->page_mkwrite()? > > Possibly, though I'd rather they didn't see such a page. Well someone needs to be taught all about this case. Question is, should it be the VFS, or should it just be the address_space(s) which brought this state about, and which care about it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/