Messages in this thread | | | Date | Thu, 11 Nov 2004 03:43:53 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] VM routine fixes |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |