cvs commit: src/sys/kern kern_intr.c subr_sleepqueue.c src/sys/geom geom_io.c src/sys/sys proc.h

[Robert Watson]

On Thu, 15 Sep 2005, Pawel Jakub Dawidek wrote:

> +>   - Add a new simple facility for marking the current thread as being in a
> +>     state where sleeping on a sleep queue is not allowed.  The facility
> +>     doesn't support recursion but uses a simple private per-thread flag
> +>     (TDP_NOSLEEPING).  The sleepq_add() function will panic if the flag is
> +>     set and INVARIANTS is enabled.
> +>   - Use this new facility to replace the g_xup and g_xdown mutexes that were
> +>     (ab)used to achieve similar behavior.
>
> So is this still possible to use mutexes in I/O paths (g_up/g_down 
> threads) or it will panic immediatelly?
>
> The policy for now was: using mutexes in a sane way is possible. The 
> question is: did we went from a warning when WITNESS is enabled to a 
> panic with INVARIANTS only?

The term "sleep" is rather overloaded in BSD kernels, and the FreeBSD 
kernel in particular.  With these changes, it is possible to lock spin and 
sleep mutexes in a TDF_NOSLEEPING region, but not perform unbounded 
sleeps, such as tsleep() and msleep().  It's also not possible to use code 
that performs such sleeps, such as malloc(9) with M_WAITOK, uma_zalloc() 
with M_WAITOK, and sx(9) locks.  So the constraints are basically the same 
as what you're allowed to do while holding a mutex, which is the invariant 
that was enforced previously by holding the g_xup and g_xdown mutexes. 
I.e., John has now formalized the mechanism by which code can assert that 
an invariant is that between two points, no sleeping shall occur, rather 
than relying on the fact that that invariant is also enforced if you hold 
a mutex.

Robert N M Watson