On Mon, 9 Jan 2006, Steven Rostedt wrote: > On Mon, 2006-01-09 at 21:16 +0100, Esben Nielsen wrote: > > > You only take the spinlocks corresponding to the current lock. What about > > the next locks in the chain? Remember those locks might not be > > futexes but a lock inside the kernel, taken in system calls. I.e. the > > robust_sem might not protect you. > > If there are n locks you need to lock n lock->wait_lock and n > > owner->task->pi_lock as you traverse the locks. That is what I tried to > > sketch in the examble below. > > The thing about this is that you can't (if the kernel is not buggy) > deadlock on the kernel spin locks. As long as you protect the locks in > the futex from deadlocking you are fine. This is because you don't grab > a futex after grabbing a kernel spin lock. All kernel spin locks > __must__ be released before going back to user land, and that's where > you grab the futexes. > Yes, but the deadlock-detect code doesn't know what is a futex and what isn't. Therefore when it starts to traverse rt_mutexes which aren't futexes it has to be _very_ carefull taking the right spinlocks. On the other hand when traversing the futexes it has to be carefull not to deadlocks on those very same spinlocks.
And yes, you _can_ traverse the lock chain without deadlocking the kernel. The code I sketched in the previouse mail should do it. Anyway, I am trying to rewrite rt_mutex to remove the spinlock deadlock altogether. My girlfriend is away with our daugther a few days so I might get time to do finish it :-) > -- Steve > > Esben
_______________________________________________ robustmutexes mailing list [email protected] https://lists.osdl.org/mailman/listinfo/robustmutexes
