From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262219AbUKKLby@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262219AbUKKLby (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 11 Nov 2004 06:31:54 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262214AbUKKLby
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 11 Nov 2004 06:31:54 -0500
Received: from mx1.redhat.com ([66.187.233.31]:25568 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S262219AbUKKLaG (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 11 Nov 2004 06:30:06 -0500
From: David Howells <dhowells@redhat.com>
In-Reply-To: <20041110182659.3f8138d6.akpm@osdl.org> 
References: <20041110182659.3f8138d6.akpm@osdl.org>  <20041109140122.GA5388@infradead.org> <20041109125539.GA4867@infradead.org> <200411081432.iA8EWfmh023432@warthog.cambridge.redhat.com> <15068.1100008386@redhat.com> <4530.1100093877@redhat.com> <20041110110145.3751ae17.akpm@osdl.org> <1100135833.4631.10.camel@localhost.localdomain> 
To: Andrew Morton <akpm@osdl.org>
Cc: David Woodhouse <dwmw2@infradead.org>, hch@infradead.org,
       torvalds@osdl.org, davidm@snapgear.com, linux-kernel@vger.kernel.org,
       uclinux-dev@uclinux.org,
       Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] VM routine fixes 
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 11 Nov 2004 11:29:36 +0000
Message-ID: <24698.1100172576@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


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

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

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

> > > 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 aren't FRV specific. They were uClinux enhancements before I got my hands
on it. They are even in your -mm3 kernel. All I did was to make the freeing
case work properly.

> >  they're the fixes required to do proper shared readable mmap with
> > !CONFIG_MMU.

That's not 100% true. They're required to do multipage mmap with !MMU. As I've
said they predate my involvement with the nommu stuff in 2.6 and 2.4 both.

David