Re: RFC: [PATCH-2.6] Add helper function to lock multiple page cache pages - nopage alternative

[Hugh Dickins <hugh@veritas.com>]

On Fri, 4 Feb 2005, Anton Altaparmakov wrote:
> On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
> > 
> > I think the point is that we can't have a "handler for writes," because 
> > the writes are being done by simple CPU Store instructions in a user 
> > program.  The handler we're talking about is just for page faults.  Other 
> 
> That was my understanding.
> 
> > operating systems approach this by actually _having_ a handler for a CPU 
> > store instruction, in the form of a page protection fault handler -- the 
> > nopage routine adds the page to the user's address space, but write 
> > protects it.  The first time the user tries to store into it, the 
> > filesystem driver gets a chance to do what's necessary to support a dirty 
> > cache page -- allocate a block, add additional dirty pages to the cache, 
> > etc.  It would be wonderful to have that in Linux.
> 
> It would.  This would certainly solve this problem.

Isn't this exactly what David Howells' page_mkwrite stuff in -mm's
add-page-becoming-writable-notification.patch is designed for?

Though it looks a little broken to me as it stands (beyond the two
fixup patches already there).  I've not found time to double-check
or test, apologies in advance if I'm libelling, but...

(a) I thought the prot bits do_nopage gives a pte in a shared writable
    mapping include write permission, even when it's a read fault:
    that can't be allowed if there's a page_mkwrite.

(b) I don't understand how do_wp_page's "reuse" logic for whether it
    can just go ahead and use the existing anonymous page, would have
    any relevance to calling page_mkwrite on a shared writable page,
    which must be used and not COWed however many references there are.

Didn't look further, think you should take a look at page_mkwrite,
but don't expect the implementation to be correct yet.

Hugh