On Fri, 2010-07-09 at 00:19 -0700, Darren Hart wrote: > I'll keep on looking, but I wanted to share what I've learned in case anyone > in another timezone is hoping to continue debugging should I fall asleep at > the helm ;-) Still making smoke here, no heat or light tho.. Q: why is it ok to call rt_mutex_proxy_unlock() without the wait_lock held? Every other path leading to rt_mutex_set_owner() seems to hold the lock. Locking it did diddly spit other than shut up my WARN_ON(). diff --git a/kernel/futex.c b/kernel/futex.c index a6cec32..f4b76d9 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -407,7 +407,9 @@ static void free_pi_state(struct futex_pi_state *pi_state) list_del_init(&pi_state->list); raw_spin_unlock_irq(&pi_state->owner->pi_lock); + raw_spin_lock(&pi_state->pi_mutex.wait_lock); rt_mutex_proxy_unlock(&pi_state->pi_mutex, pi_state->owner); + raw_spin_unlock(&pi_state->pi_mutex.wait_lock); } if (current->pi_state_cache) -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
