kernel panic on HEAD from Oct. 4th sources

[Matthew Dillon]

:1/ On a UP system, there can be at most one non-sleeping thread running
:kernel-side and this thread can be preempted if and only if it explicitly
:relinquishes the cpu, for example by calling tsleep().
:...
:
:5/ The race condition occurs if the call to vm_waitproc() in kern_wait() blocks
:and another thread enters the kernel to handle a sysctl() call.
:
:Thanks in advance,

    Not exactly.  You hit the answer in #1 ... the keyword there is 
    non-sleeping.

    Many things in the kernel can cause a process to block for short periods
    of time.  There are many points in the exit code where a process can
    block.  When this occurs, another process can run and 'see' the exiting
    process in its half-torn-down state.  This can happen as easily on a UP
    system as on a MP system.

    One thing that *cannot* cause a thread to block is an interrupt.  An
    interrupt thread can preempt the currently running thread, but the
    preemption never actually deschedules the original thread.  If the
    interrupt thread finishes or blocks or does anything that causes it
    to lose control, then control is immediately returned to the original
    thread.

    This means that the sort of blockages we are talking about in mainline
    threads, for example in the exit code, are explicitly in the exit code
    and cannot be caused by events external to that code.

    For example, when the exit code close()'s all of a process's file
    descriptors the act of closing those descriptors might require temporary
    vnode and other locks, all of which can temporarily block the exiting
    process.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>