>Argh.  This is a similar problem that happened on the i386 when I was
>pool'ifying aobj structures.
>Basically, curproc is NULL (cpu_exit sets it to NULL), and you may go
>to sleep waiting for memory, which would lose because curproc is NULL,
>hence the diagnostic test and the panic.
>Chuck?  What's the best thing to do, here?  Doesn't look like we can
>perform the same sort of test that fixed the aobj problem...


i believe the pool allocator has uncovered a design problem in the
process exit code path.


looking at kern_exit.c, the final thing it does is set curproc
to NULL and call cpu_exit.   once curproc is NULL, we are no longer
allowed to sleep.    that means that we really have no business
calling vm_map_lock() in cpu_exit()  or any function it calls [because 
vm_map_lock() can sleep if the map is busy... not likely to be the 
case for the kernel map because we are single threaded right now, 
but it is best not to depend on that in the future...]

looking at the cpu_exit() functions on various ports, they all
seem to call uvmspace_free() and various pmap functions.  i believe 
there are several calls to vm_map_lock in that general area.   
this seems bad.   [maybe we should add a DIAGNOSTIC to vm_map_lock 
to check for a NULL curproc to catch these?]


it isn't clear to me what the best way to clean this up is.
i guess one temptation might be to push the clearing of curproc
back later into the cpu_exit function...?


chuck