lkml.org 
[lkml]   [2004]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.041 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site