Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes

From: Thomas Gleixner
Date: Wed Jun 04 2014 - 16:42:07 EST


On Wed, 4 Jun 2014, Brad Mouring wrote:
> On Wed, Jun 04, 2014 at 09:53:16PM +0200, Thomas Gleixner wrote:
> > Your change wreckages the rt_mutex_owner(lock) == top_task test
> > simply because in that case:
> >
> > (rt_mutex_owner(lock) && rt_mutex_owner(lock) != task)
> >
> > evaluates to true.
>
> Ah. Yeah. I haven't tested this but it seems sane to me.
>
> >
> > So we want this:
> >
> > Index: tip/kernel/locking/rtmutex.c
> > ===================================================================
> > --- tip.orig/kernel/locking/rtmutex.c
> > +++ tip/kernel/locking/rtmutex.c
> > @@ -375,6 +375,26 @@ static int rt_mutex_adjust_prio_chain(st
> > * walk, we detected a deadlock.
> > */
> > if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
> > + /*
> > + * If the prio chain has changed out from under us, set the task
> > + * to the current owner of the lock in the current waiter and
> > + * continue walking the prio chain
> > + */
> > + if (rt_mutex_owner(lock) && rt_mutex_owner(lock) != task &&
> > + rt_mutex_owner(lock) != top_task) {
> > + /* Release the old owner */

That's not the old owner. It's the task which was blocked in the lock
chain before we dropped the locks and got preemptible. So we come here
just in the case that the task is now blocked on orig_lock.

We really want to be more than careful about the comments here. The
damned thing is complex enough already, so confusing comments are
actually worse than no comments.

Care to resend?

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/