Messages in this thread | | | Subject | Re: [RFC][PATCH 0/7] lockdep: Support recurise-read locks | From | Tetsuo Handa <> | Date | Fri, 22 Apr 2011 16:44:49 +0900 |
| |
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, and lockdep alart depends on which function was called first.
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!)
| |