NetBSD Problem Report #11817

Received: (qmail 27892 invoked from network); 26 Dec 2000 20:37:57 -0000
Message-Id: <Pine.SOL.4.21.0012262005330.229-100000@draco.cus.cam.ac.uk>
Date: Tue, 26 Dec 2000 20:37:56 +0000 (GMT)
From: Ben Harris <bjh21@netbsd.org>
Sender: Ben Harris <bjh21@cus.cam.ac.uk>
To: gnats-bugs@gnats.netbsd.org
Subject: ps(1) panics on arm26

>Number:         11817
>Category:       port-acorn26
>Synopsis:       ps(1) panics on arm26
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-arm26-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 26 20:38:00 +0000 2000
>Closed-Date:    Fri Jan 05 13:37:39 +0000 2001
>Last-Modified:  Fri Jan 05 13:37:39 +0000 2001
>Originator:     Ben Harris
>Release:        2000-12-26
>Organization:
	MEMC fan club
>Environment:
Any arm26 system.

>Description:
Running ps(1) causes a kernel panic when ps tries to fetch its own argv.

The problem is that sys___sysctl() forces the stck page the ps is using to
recieve the target process's argv to be wired, then tries to map the page
again in kernel VM, since it's the source of the argv in question.  The
MEMC in arm26 systems can only cope with one logical mapping of each
physical page, so this can't work, since it isn't allowed to cause page
faults on the first mapping of the page.

>How-To-Repeat:
Boot a NetBSD/arm26 system single-user.  Run ps.

# ps
PID TT STAT   TIME COMMAND
 10 E0 Ss   0:02.58 -sh
new: pmap = 0x21f0230, ppn = 233, lpn = 936
old: pmap = 0x22fa010, ppn = 233, lpn = 767
panic: Mapping clash not handled
Stopped in pid 12 (ps) at       cpu_Debugger+0x10:	bl	kdb_trap
db> _

Stack backtrace (registers removed):
panic
pmap_enter
uvm_fault
data_abort_handler
kcopy
uiomove
uvm_io
fill_eproc
kern_sysctl
sys___sysctl
syscall
swi_handler

>Fix:

One simple solution to this is to have pmap_enter return an error when
asked to do this, rather than panicking.  This, though, will at best cause
ps to hang, which isn't very useful.

Another possibility that's been suggested to me is to effectively
re-implement part of uvm_fault in the pmap module, so that that can
map in wired pages without needing to bother uvm_fault about them.  This
duplication of effort seems silly to me, but it may turn out to be the
easiest solution to implement.  It would also be necessary for pmap_enter
to be careful about which wired pages it unmapped, since some of them may
contain information needed by the pmap to map them back in.

To me, it seems that the problem is ultimately caused by only having one
"wired" bit.  "Wired" officially means "may not cause calls to uvm_fault",
but it's often (as in this case) used just to ensure that accesses to a
page don't send the accessing process to sleep.  It seems to me that these
two concepts should be separated, so that pmaps aren't restricted from
throwing away mappings of most wired pages, and are told explicitly which
ones are really important.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: bjh21 
State-Changed-When: Fri Jan 5 05:37:09 PST 2001 
State-Changed-Why:  
Believed fixed.  Thanks to chs. 
>Unformatted:

Home	PR Database Search