Re: [ANNOUNCE] 3.2.9-rt17

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.