We're currently tripping accross the following KASSERT in
subr_turnstile.c (in 5.3.0 RELEASE):
/*
* XXX: The owner of a turnstile can be stale if it is the
* first thread to grab a slock of a sx lock. In that case
* it is possible for us to be at SSLEEP or some other
* weird state. We should probably just return if the state
* isn't SRUN or SLOCK.
*/
KASSERT(!TD_IS_SLEEPING(td),
("sleeping thread %p (pid %d) owns non-sleepable lock %p",
td, td->td_proc->p_pid, ts))
This is in propagate_priority().
However, propagate_priority() is only called in one place, by
turnstile_wait(), and turnstile_wait() in turn is only called by
_mtx_lock_sleep() which in turn is only used for sleep mutexes.
TD_IS_SLEEPING() really means the SLEEPING inhibitor is set which in
turn seems to mean that thread is in fact on a sleepq - which is used
for various wait channels and timeouts.
So I'm just trying to understand why it's a 100% assertion for any
holder of the turnstile for a sleep mutex sleeping.
Thanks,
--
Mark Gooderum
Vernier Networks, Inc.
mark@verniernetworks.com
On Tue, 2004-11-23 at 22:21, Mark Gooderum wrote:> We're currently tripping accross the following KASSERT in > subr_turnstile.c (in 5.3.0 RELEASE): > > /* > * XXX: The owner of a turnstile can be stale if it is the > * first thread to grab a slock of a sx lock. In that case > * it is possible for us to be at SSLEEP or some other > * weird state. We should probably just return if the state > * isn't SRUN or SLOCK. > */ > KASSERT(!TD_IS_SLEEPING(td), > ("sleeping thread %p (pid %d) owns non-sleepable lock %p", > td, td->td_proc->p_pid, ts)) > > This is in propagate_priority(). > > However, propagate_priority() is only called in one place, by > turnstile_wait(), and turnstile_wait() in turn is only called by > _mtx_lock_sleep() which in turn is only used for sleep mutexes. > > TD_IS_SLEEPING() really means the SLEEPING inhibitor is set which in > turn seems to mean that thread is in fact on a sleepq - which is used > for various wait channels and timeouts. > > So I'm just trying to understand why it's a 100% assertion for any > holder of the turnstile for a sleep mutex sleeping.Priority inheritance is needed to avoid blocking interrupt threads for a long time. A thread sleeping while holding a mutex would break priority inheritance. Another reason is that this would add a hidden dependency to the wakeup thread - this can easily lead to deadlocks. Can you find out where the owner of the mutex is sleeping? Stephan