On Tue, 10 Jun 2014, Thomas Gleixner wrote: > On Tue, 10 Jun 2014, Steven Rostedt wrote: > > On Tue, 10 Jun 2014 20:08:37 +0200 (CEST) > > Thomas Gleixner <t...@linutronix.de> wrote: > > > > > > > > Perhaps it could simply do ->owner = RT_MUTEX_HAS_WAITERS to make this > > > > more > > > > clear... > > > > > > Good point. The new owner can cleanup the mess. > > > > > > > I thought about this too. It should work with the added overhead that > > every time we go into the unlock slow path, we guarantee that the next > > lock will go into the lock slowpath. > > > > As long as the new acquired lock does a fast unlock, then we get out of > > this spiral. > > The alternative solution is to document WHY this is safe. I think I > prefer that one :)
And actually we keep the waiter bit set in wakeup_next_waiter() because we only dequeue the waiter from the lock owners pi waiter list, but not from the lock waiter list. rt_mutex_set_owner() sets the waiters bit if the lock has waiters. I agree with Oleg that this is not obvious from the code. So I add both a comment and open code it. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/