[lkml]   [2006]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: _cpu_down deadlock [was Re: 2.6.19-rc1-mm1]
    On Wednesday October 11, 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
    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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-12 01:49    [W:0.020 / U:22.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site