cvs commit: src/sys/kern kern_intr.c subr_sleepqueue.c
src/sys/geom geom_io.c src/sys/sys proc.h
rwatson at FreeBSD.org
Thu Sep 15 14:04:22 PDT 2005
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
Robert N M Watson
More information about the cvs-src