kernel panic on HEAD from Oct. 4th sources
dillon at apollo.backplane.com
Sun Oct 21 09:29:26 PDT 2007
: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
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
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
<dillon at backplane.com>
More information about the Bugs