[lkml]   [2011]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH 0/7] lockdep: Support recurise-read locks
    2011/4/22 Tetsuo Handa <>:
    > Yong Zhang wrote:
    >> > Also, something is still wrong because lockdep fails to detect the problem
    >> > for "cat /proc/locktest1 /proc/locktest2" and
    >> > "cat /proc/locktest3 /proc/locktest4" cases.
    >> It fails because we never add the recursive read to prev->after evev if
    >> it passed the validation.
    > Thanks. But why "cat /proc/locktest1 /proc/locktest2" is "the recursive read"
    > and "cat /proc/locktest2 /proc/locktest1" is not "the recursive read"?
    > Both are serialized. Both hold and release the same lock.
    > The only difference is which function was called first,

    When you are using rwlock_acquire*(), your four testcases are
    all failed, the reason I have explained.

    When you are using spin_acquire()/spin_release() in read_seqbegin2()/
    read_seqretry2(), if you call locktest2/locktest4 firstly, the chain will
    be established, so when call locktest1/locktest3, lockdep warns on it.
    But if you call locktest1/locktest2 firstly, the chain will not be established
    just because recursive read is not added to prev->after.

    > and lockdep alart depends on which function was called first.

    No, it's not related with which function is called firstly, instead it's
    the current behavior of lockdep.

    > It sounds to me that Documentation/lockdep-design.txt says
    > timing (i.e. which function was called first) is not important.
    > 172 Proof of 100% correctness:
    > 173 --------------------------
    > 174
    > 175 The validator achieves perfect, mathematical 'closure' (proof of locking
    > 176 correctness) in the sense that for every simple, standalone single-task
    > 177 locking sequence that occurred at least once during the lifetime of the
    > 178 kernel, the validator proves it with a 100% certainty that no
    > 179 combination and timing of these locking sequences can cause any class of
    > 180 lock related deadlock. [*]
    > 181
    > 182 I.e. complex multi-CPU and multi-task locking scenarios do not have to
    > 183 occur in practice to prove a deadlock: only the simple 'component'
    > 184 locking chains have to occur at least once (anytime, in any
    > 185 task/context) for the validator to be able to prove correctness. (For
    > 186 example, complex deadlocks that would normally need more than 3 CPUs and
    > 187 a very unlikely constellation of tasks, irq-contexts and timings to
    > 188 occur, can be detected on a plain, lightly loaded single-CPU system as
    > 189 well!)

    This is true, but currently we take different action on recursive read
    which seems needed to be improved. :)


    Only stand for myself

     \ /
      Last update: 2011-04-22 10:03    [W:0.021 / U:29.848 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site