>Number:         33235
>Category:       kern
>Synopsis:       uvm_mapent_reserve calls uvm_kmapent_alloc with user vm_map (under sys_execve)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 11 03:40:00 +0000 2006
>Originator:     Jed Davis
>Release:        NetBSD 3.0
>Organization:
PANIX Public Access Internet and UNIX, NYC
>Environment:
System: NetBSD mail2.panix.com 3.0 NetBSD 3.0 (PANIX-STD-MP-DEBUG) #0: Fri Apr  7 04:35:36 EDT 2006  root@juggler.panix.com:/devel/netbsd/3.0/src/sys/arch/i386/compile/PANIX-STD-MP-DEBUG i386
Architecture: i386
Machine: i386
>Description:

Dual-processor machine running 3.0/i386 with DIAGNOSTIC/DEBUG/LOCKDEBUG;
had no problems under 2.0.3, but crashes often under 3.0 (thus the debug
options).  panic is thus:

panic: kernel diagnostic assertion "vm_map_pmap(map) == pmap_kernel()" failed: file "../../../../uvm/uvm_map.c", line 4151
Stopped in pid 11143.1 (sh) at  netbsd:cpu_Debugger+0x4:        leave
db{0}> tr
cpu_Debugger(cf0885f8,c042d692,390,c04b7d20,cf84fd44) at netbsd:cpu_Debugger+0x4
panic(c0488660,c04254fd,c0466000,c043153c,1037) at netbsd:panic+0x121
__main(c04254fd,c043153c,1037,c0466000,cf0885f8) at netbsd:__main
uvm_kmapent_alloc(cfa702a0,0,0,c04c81e0,0) at netbsd:uvm_kmapent_alloc+0x30b
uvm_mapent_reserve(cfa702a0,cf84fd44,2,0,0) at netbsd:uvm_mapent_reserve+0x54
uvm_unmap1(cfa702a0,0,bfc00000,0,c04c81e0) at netbsd:uvm_unmap1+0x1b
uvm_deallocate(cfa702a0,0,bfc00000,0,0) at netbsd:uvm_deallocate+0x32
sys_execve(cf52f7c4,cf84ff64,cf84ff5c,c04930c4,c02578e3) at netbsd:sys_execve+0xbd9
syscall_plain() at netbsd:syscall_plain+0x1a5
--- syscall (number 59) ---
0xbdb2b15f:

We have a core file (and debug symbols, too).  I notice that neither the
name nor comment nor assertions of uvm_mapent_reserve suggests that it
won't take non-kernel maps; yet it passes the map to uvm_kmapent_alloc,
which does have such a restriction.  I don't know enough about UVM to
say where the problem is, or if that might be a red herring.

>How-To-Repeat:

Running 3.0 on this host (a mail relay), with MP enabled, for a few
hours seems to yield one panic or another.  (Worked fine for years under
2.0.3, so very unlikely to be hardware.)

>Fix:

As a somewhat unsatisfactory workaround, booting a uniprocessor kernel 
seems to make the host not panic all the time.