Re: [ANNOUNCE] 3.2.9-rt17

[Peter Zijlstra]

On Thu, 2012-03-08 at 15:10 -0500, Steven Rostedt wrote:
> 
> By doing a spin_trydeadlock() while still holding the d_lock, if the
> holder of the i_lock was blocked on that d_lock then it would detect the
> failure, and release the lock and continue the loop. This doesn't solve
> anything. Just because we released the lock, we are still preempting the
> holder of the d_lock

->i_lock, right?

> , and if we are higher in priority, we will never let the owner run.

So, suppose:

task-A				task-B

lock ->i_lock
				lock ->d_lock
lock ->d_lock <blocks>
				trylock ->i_lock

In this case B's trylock will insta-fail (with -EDEADLK) and we unlock
->d_lock in the existing retry logic. That dropping of ->d_lock will
then wake A, but since B is higher prio A we don't actually run A and
B's retry loop will re-acquire ->d_lock.

Crap.. there's also the fact that A doesn't get (or stays) boosted.

I can only think of ugly things to do, like on the deadlock scan, force
assign the first waiter of the inverted lock to owner (in this case the
deadlock is on ->d_lock so assign A), so that the moment we release
->d_lock our re-acquisition fails because its already owned by A, at
that point B will block and boost A.

There's just the little detail of having two owners for a little while..

> But just sleeping a tick sounds like a heuristic that may someday fail.

Oh absolutely agreed, ideally someone would find a way to implement the
-EDEADLK stuff for rt-mutex in a way that doesn't make tglx sad and
actually works.
--
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/