Messages in this thread | | | From | Neil Brown <> | Date | Thu, 12 Oct 2006 09:46:50 +1000 | Subject | Re: _cpu_down deadlock [was Re: 2.6.19-rc1-mm1] |
| |
On Wednesday October 11, akpm@osdl.org wrote: > > > > So A waits on B and C, C waits on B, B waits on A. > > Deadlock. > > Except the entire operation is serialised by the the two top-level callers > (cpu_up() and cpu_down()) taking mutex_lock(&cpu_add_remove_lock). Can > lockdep be taught about that?
So you are saying that even though we have locking sequences A -> B and B -> A, that cannot - in this case - cause a deadlock as both sequences only ever happen under a third exclusive lock C, So when lockdep records a lock-dependency A -> B, it should also record a list of locks that are *always* held when that dependency occurs. Then, when it finds a new dependency and does loop detection, it should exclude from the path any dependency which is always under a lock that some other dependency in the path is always under. Also, loop checking as to happen both when a new dependency is found, and when a lock is removed from the set of locks that protect the dependency.
Recording stack traces might be interesting as you potentially need to record a trace for ever minimal set of locks that the dependency is created under.
So the ball is back in Ingo's court ?
Though it is odd that the warning doesn't trigger every time....
> > > Who do we blame this on? Are you still the cpu-hot-plug guy Rusty? > > It's fun blaming Rusty for stuff, but he can dodge this one with > more-than-usual ease, I'm afraid.
In that case, I was never dreaming of blaming him, only letting him know that there is a lock-dep warning in code that he might be seen as responsible for - just in case anyone does blame him. Yes. That's what I was doing. Definitely.
NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |