Re: [PATCH] VM routine fixes

From: Andrew Morton
Date: Wed Nov 10 2004 - 21:28:25 EST


David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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?
>
> Because in the absence of an MMU, an mmap of a large region (like an
> executable) has to be satisfied by a large enough allocation followed by
> a read.

That's currently implemented via this:

/*
* We need to reference all the pages for this order, otherwise if
* anyone accesses one of the pages with (get/put) it will be freed.
*/
for (i = 0; i < (1 << order); i++)
set_page_count(page+i, 1);

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. I wonder if the
no-buddy-bitmap patches allow that? And if they've been tested with that?

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.

> > If someone could explain the reasoning behind the current code, and the FRV
> > enhancements then perhaps we could work something out.
>
> I think these parts aren't FRV-specific; they're the fixes required to
> do proper shared readable mmap with !CONFIG_MMU. That was a prerequisite
> for the ELF-FDPIC executable format, which allows real shared libraries
> on uClinux.
>

OK.
-
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/