Re: Address space operations questions

[Zach Brown <zab@zabbo.net>]

Bryan Henderson wrote:
>>So, semantics of ->sync_page() are roughly "kick underlying storage
>>driver to actually perform all IO queued for this page, and, maybe, for
>>other pages on this device too".
> 
> 
> I prefer to think of it in a more modular sense.  To preserve modularity, 
> the caller of sync_page() can't know anything about I/O scheduling.  So I 
> think the semantics of ->sync_page() are "Someone is about to wait for the 
> results of the previously requested write_page on this page."  It's 
> completely up to the owner of the address space to figure out what would 
> be appropriate to do given that information.

Though I agree with your desire for a "modular" interpretation, I'm
going disagree your description of the information sync_page() provides.
 Nikita's vague description is closer to the truth because sync_page()
is vague.

If you follow the callers of sync_page() you quickly find that what it
*really* means to be called in sync_page() is that you're being told
that some process is about to block on that page.  For what reason, you
can't know from the call alone.  Waiting for read to complete and
unlock?  Waiting for writeback to clear the writeback bit?  Some
processes just happened to race to lock_page() on the same page for
reasons that have nothing to do with IO?

And the not-so-initiated might think that sync_page() is called with the
page lock just like the other ops.  That's obviously not the case, as it
is called when the page lock can't be acquired, but it makes actually
*doing* something with that page argument perilous.  Synchronization is
left to the sync_page() callee.

For example, cachefs seems to be among the very few who don't provide
block_sync_page() directly.  All it does is printk() and then call
block_sync_page().  In that single line of code it derefs page->mapping
without checking and so can probably fatally race with truncation and
the nulling of page->mapping.

- z