Re: [PATCH] VM routine fixes
From: Andrew Morton
Date: Thu Nov 11 2004 - 06:46:43 EST
David Howells <dhowells@xxxxxxxxxx> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/