Messages in this thread | | | Date | Fri, 22 Apr 2011 16:01:05 +0800 | Subject | Re: [RFC][PATCH 0/7] lockdep: Support recurise-read locks | From | Yong Zhang <> |
| |
2011/4/22 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>: > 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 validation which seems needed to be improved. :)
Thanks, Yong
-- Only stand for myself
| |