On Thu, 07 May 1998 23:46:57 +0100 
 "Neil A. Carson" <neil@causality.com> wrote:

 > > Yup, NetBSD/i386 gives exactly the same error. (NetBSD 1.2.1 though).
 > 
 > Tried it on my FreeBSD machine and it worked fine, so a fix is probably

...what is the error, exactly?  Note that the behavior is dependent on
the platform's pmap implementation.

Anyhow, on an i386 with UVM + PMAP_NEW, I'm getting EAGAIN.  This can
be caused by:

	- the request causes the number of wired pages to exceed the
	  system max allowed wired pages

	- the request causes the process to exceed the process's
	  limit on locked memory (this is pmap-dependent: it requires
	  a pmap_wired_count() macro)  Note that the i386 PMAP_NEW
	  does not, apparently, implement pmap_wired_count().

On my Alpha with UVM + PMAP_NEW, when the program is modified to reflect
a page (8k on alpha) of memory that's actually mapped (i.e. first page of
user text which begins at 0x120000000 on the Alpha, not at NBPG), it works
fine.

Looking at Mach VM vs. UVM in this case, the mlock() system call is
essentially identical.

Given that it works on a platform that provides a pmap_wired_count()
macro, I'd say this is a bug in the arm32 pmap, not the MI VM code.

 > out there in that tree. I wonder if it's gone away with UVM? Fixing the
 > Mach VM isn't done in the NetBSD tree any more.

That's not really a fair (or even true!) statement for a couple of reasons:

	- Serious bugs in Mach VM will be, and have been, fixed (e.g. the
	  mmap security bug some months ago, other major problems).  Don't
	  make blanket statements about NetBSD Project policy unless you're
	  in a position to do so (and, I can say with reasonable authority,
	  you are not).

	- It's like you didn't even do any analysis on the problem!  I mean,
	  I'm busy trying to get a paper edited for USENIX (so I can FedEx
	  it tomorrow), yet I could spare the 5 minutes it took to actually
	  demonstrate that it might be a bug in the arm32 pmap.

Now, it is true that non-critical problems that are the result of the
Mach VM design probably won't be "fixed", because we have a better solution
already, and in fact several ports (5 at last count) now use UVM as the
only supported VM system on that platform.

If, in -current, ports which are having repeated problems with Mach VM
haven't yet switched to UVM ... well, it's no one's fault but the port
master's.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 428 6939