On Mon, Apr 28, 2008 at 09:31:25PM +0100, David Laight wrote:
On Mon, Apr 28, 2008 at 03:36:01PM +0000, Andrew Doran wrote:
Log Message:
Add MI code to support in-kernel preemption. Preemption is
deferred by
one of the following:
- Holding kernel_lock (indicating that the code is not MT safe).
- Bracketing critical sections with kpreempt_disable/
kpreempt_enable.
- Holding the interrupt priority level above IPL_NONE.
Shouldn't the list also include 'holding any spinlock' ?
Or do we only have spinlocks that raise the IPL ?
IIRC, it's still possible to get a pure spin mutex at IPL_NONE. It's
usually
unsafe to use one though. Device interrupts would not be blocked by
it so
the mutex would have a strict ordering constraint against
kernel_lock (which
can be taken by interrupt handlers). Perhaps we should add a KASSERT
or
panic to prevent initializing one of those?
It's certainly possible to use a cpu_simple_lock at a low IPL, but
if you're
playing with stuff at such a low level then the chances are that
there are
already some ugly sync issues at hand, so the sync issues are
probably one of
the major problems to be solved..
Thanks,
Andrew