Re: when can we tsleep() ?

[Andrew Doran <ad%netbsd.org@localhost>]

On Sat, Oct 18, 2008 at 10:25:17PM +0200, Manuel Bouyer wrote:

> this is related to kern/39725. We have cpu_intr_p() which tells us
> if we're in interrupt context or not. But there's other cases where
> it's not safe to call tsleep (e.g. from soft interrupt context, maybe
> others). If there a function or check that can tell us if it's safe
> to use tsleep() or not ?

There is no function directly available to do that. I don't believe it is
something you should need to check on the fly other than for an assertion.

It is safe to sleep with condition variables or tsleep when running within a
kthread or a user lwp. So if you are running because of kthread_create(), or
are running because a user process called into the kernel (a system call or
trap) then you can sleep. Otherwise it is not permitted.

Soft interrupts also have thread context but can sleep only to acquire a
mutex or a rwlock. Use of a condition variable or tsleep will cause an
assertion to fire because those typically indicate a longer wait. It's not
allowed because the soft interrupts are a limited resource that are shared
among lots of subsystems. If they stall for any length of time then the
system will become unresponsive.

Nothing can sleep in the idle loop, or in a hardware interrupt handler. One
exception is the interrupt that does kernel preemption. It runs on the the
preempted LWP's stack, without its own context, and calls to mi_switch().
However that's done under carefully controlled circumstances, when it is
known that it's safe to switch.

Long term sleeps should not happen while holding most locks, for example
proc::p_lock, as these can cause the system to respond poorly or worst case,
deadlock. With some locks we can't avoid it and it's not a problem, example:
vnode locks. There are no runtime assertions to catch these problems so as a
general rule it's avoided.

Andrew