Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes
From: Thomas Gleixner
Date: Wed Jun 04 2014 - 11:32:49 EST
On Tue, 3 Jun 2014, Steven Rostedt wrote:
> On Fri, 23 May 2014 09:30:10 -0500
> "Brad Mouring" <bmouring@xxxxxx> wrote:
> > /* Deadlock detection */
> > 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) {
No, sorry. That's wrong.
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.
Aside of that we need to figure out whether the lock chain changed
while we dropped the locks even in the non dead lock case. Otherwise
we follow up the wrong chain there.
T0 blocked on L1 held by T1
T1 blocked on L2 held by T2
T2 blocked on L3 held by T3
So we walk the chain and do:
T1 -> L2 -> T2
Now here we get preempted.
T3 releases L3
T2 gets L3
T2 drops L3 and L2
T2 blocks on L4 held by T4
T4 blocked on L5 held by T5
So we happily boost T4 and T5. Not what we really want to do.
Nasty, isn't it ?
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/