Messages in this thread | | | Date | Tue, 5 Aug 2008 00:30:11 +0200 | From | Andrea Arcangeli <> | Subject | Re: [PATCH] workaround minor lockdep bug triggered by mm_take_all_locks |
| |
On Mon, Aug 04, 2008 at 02:42:28PM -0700, Arjan van de Ven wrote: > yes lockdep will only complain WHEN you take them in the wrong order > > But you claimed you would for sure be in a deadlock at that point which > is generally not correct.
I already said I didn't know about that despite having spent a fair amount of time trying to understand why lockdep crashes systems at boot about an year ago. I admit I didn't understand much about it and reducing its computation time didn't look feasible, perhaps my fault, and I'm glad if Peter found a way to make it boot after 1 year.
> this comment totally puzzles me... rather than calling you naive... > where was this said or even implied????
It was just a logical conclusion of the statement that lockdep will warn of the following classes of locking bugs: "lock inversion scenarios"... There's no warning anywhere that it might not find them at all. Or point me to where it is warned you still have to read the code and verify it yourself, or you still risk to AB BA in production. If it was warned I wouldn't have mentioned it, people seem to talk like if lockdep is a checker doing static analyses of all paths when it can't.
Partly of what I said before is true, even if I didn't understand the actual details of the AB BA memory it has by reading the code: the BA may happen only when system is OOM etc... so even lockdep memory may never find it. So my warning that code might AB BA deadlock even if lockdep doesn't warn sounds fair enough and without it I'm still afraid it can lead to developers think everything is ok with regard to AB BA. In any case (even if everyone already understand lockdep better than I did before this discussion), even if I'm wrong a sign of warning that lockdep isn't enough, can't hurt.
| |