kern/46286: posix_spawn induced panic

[Thomas Klausner <wiz%NetBSD.org@localhost>]

>Number:         46286
>Category:       kern
>Synopsis:       posix_spawn induced panic
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 01 11:15:01 +0000 2012
>Originator:     Thomas Klausner
>Release:        NetBSD 6.99.4
>Organization:
Curiosity is the very basis of education and if you tell me that 
curiosity killed the cat, I say only that the cat died nobly.
- Arnold Edinborough
>Environment:
        
        
System: NetBSD yt.nih.at 6.99.4 NetBSD 6.99.4 (YT) #8: Fri Mar 30 08:08:11 CEST 
2012 wiz%yt.nih.at@localhost:/archive/cvs/src/sys/arch/amd64/compile/obj/YT 
amd64
Architecture: x86_64
Machine: amd64
>Description:
When building NetBSD with clang on a clang based userland+kernel, I get 
repeatable panics.
Copied from screenshot:
fatal page faultfatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff8040e27e cs 8 rflags 10246 cr2 0 cpl  rsp 
ff...e81165d4860
kernel: page fault t
                             =0
pStopped in pid 18769.1 (x86_64--netbsd-c) at    netbsd:pmap_deactivate+0x93:
 m
ovq     0(%rax),%rbx
pmap_deactivate() at netbsd:pmap_deactivate+0x93
mi_switch() at netbsd:mi_switch+0x2c5
sleepq_block() at netbsd:sleepq_block+0xa4
turnstile_block() at netbsd:turnstile_block+0x3d4
mutex_vector_enter() at netbsd:mutex_vector_enter+0x223
pmap_create() at netbsd:pmap_create+0x140
uvmspace_init() at netbsd:uvmspace_init+0x4b
uvmspace_alloc() at netbsd:uvmspace_alloc+0x39
uvmspace_exec() at netbsd:uvmspace_exec+0xf8
execve_runproc() at netbsd:execve_runproc+0xd0
spawn_return() at netbsd:spawn_return+0x39e

Chuck Silvers analyzes:
looks like a bug in the posix_spawn() stuff, yea.  we're trying to sleep
before the current process has a pmap or even a vmspace, which isn't going to 
work.
even though the new thread is now created as non-preemptable, it needs to sleep
because it's taking pmaps_lock which must be held by another thread that is
sleeping, which I'll guess is because the other thread was preempted.
it would be better to have these posix_spawn() processes use proc0's vmspace
until they can allocate their own.

>How-To-Repeat:
For me, just building a NetBSD using clang on a NetBSD built using clang.
>Fix:
Not provided.

>Unformatted: