On Wed, Jun 04, 2014 at 08:02:16PM +0200, Thomas Gleixner wrote:

On Wed, 4 Jun 2014, Steven Rostedt wrote:

quoted

On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
Thomas Gleixner [off-list ref] wrote:

quoted

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 ?

Actually, we may go up a chain, but we never do any unnecessary
boosting. That's because the boost is done with rt_mutex_adjust_prio()
which gets the prio from rt_mutex_getprio() which reads the
task->normal_prio and compares it to the task_top_pi_waiter(task)->prio,
which will always be correct as we have the necessary locks.

Indeed.

I had thought through how to try to determine, from what we knew at
this point, whether or not we were walking a different chain for just
this concern, but I had convinced myself that it would be cumbersome,
error-prone, and, as pointed out here, not vital.

quoted

And we don't even need to worry about the chain we miss. That is, if
task A is blocked on a lock owned by D at the time, but as we go up the
chain, D releases the lock and B grabs it, B will still up its priority
based on the waiters of the lock (that is A), and if B blocks, it will
boost the tasks that own the lock it blocks on, where B is still
influenced by A.

The fact that we only update the prio based on the actual waiters and
don't carry a prio up the chain (which you designed, and I thought was
quite ingenious by the way), we may waste time going up a chain, but
the priority inheritance is still accurate.

Duh. I actually had to lookup my notes from back then. There is even a
lenghty IRC discussion about not propagating the least waiters prio,
but lookup the actual lock waiters. Good, so we just walk for nothing
and waste some cpu cycles.

I put the check within the deadlock detection block to try to minimize
this case. As evidenced by the spinning on this, it's a rare case where
your userspace code has to be doing some wacky (but valid) stuff.

My brain still suffers from 3 days staring into futex.c

I'll fixup the check so it wont break the real deadlock case and queue
it.

How would the change break the real deadlock case?

Thanks,

	tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html