Re: [PATCH] VM routine fixes

[Andrew Morton]

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/