lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Apr 2011 16:44:49 +0900 From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> To: yong.zhang0@...il.com Cc: a.p.zijlstra@...llo.nl, rostedt@...dmis.org, tglx@...utronix.de, mingo@...e.hu, linux-kernel@...r.kernel.org Subject: Re: [RFC][PATCH 0/7] lockdep: Support recurise-read locks 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!) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists