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-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
