Re: [PATCH] VM routine fixes

[Andrew Morton <akpm@osdl.org>]

David Howells <dhowells@redhat.com> wrote:
>
> 
> > > On Wed, 2004-11-10 at 11:01 -0800, Andrew Morton wrote:
> > > > Why _does_ !CONFIG_MMU futz around with page counts in such weird ways
> > > > anyway?  Why does it have requirements for higher-order pages which
> > > > differ from !CONFIG_MMU?
> 
> The problem is ptrace() and various /proc/<pid/ files; or more properly, the
> problem is access_process_vm() and suchlike.
> 
> When one process goes rooting around in another process's memory map, it
> increments the refcount on the page it is looking at to stop it going away.
> 
> The problem on uClinux is that a process can have multipage chunks mapped into
> userspace, and access_process_vm() can look at a page in the middle of such a
> span.
> 
> Without this change, bad_page() is called when access_process_vm() calls a
> put_page() on a page in the middle because its refcount would say it's no
> longer in use and then put_page() would then attempt to free the page.
> 
> access_process_vm() guards against the target page going away due to the
> target process exiting at an inconvenient moment by pinning the target mm and
> holding its semaphore.

Compound pages will fix all that up.  You take a ref on any of the subpages
and that will pin the entire higher-order page.

> > I assume the CONFIG_MMU logic assumes that it's legal to physically free a
> > single page from inside the middle of a higher-order page.
> 
> No, it isn't. munmap() is prohibited from releasing anything other than a
> complete mmap() on uClinux.

hrm.  I'd have thought that such a restriction would be unnecessary if we
get the page refcounting done right.  With, say, compound pages!

Maybe the restriction is there for other reasons.

> > See, if we enable the compound page logic if !CONFIG_MMU then all this
> > stuff just goes away and the page refcounting is controlled purely by the
> > head page.  A get_page() or a put_page() against any of the constituent
> > pages will manipulate the head page's refcount.
> 
> That's true to a point, and probably a reasonable idea, assuming that compound
> pages aren't limited in size to TLB-specific values. If they are, then it
> makes no real difference.

Compound pages are just a way of handling refcounting of a higher-order
page.  Nothing to do with TLBs at all.