Messages in this thread | | | Subject | Re: [PATCH] workaround minor lockdep bug triggered by mm_take_all_locks | From | Peter Zijlstra <> | Date | Mon, 04 Aug 2008 22:37:22 +0200 |
| |
On Mon, 2008-08-04 at 22:15 +0200, Andrea Arcangeli wrote: > On Mon, Aug 04, 2008 at 08:48:59PM +0200, Peter Zijlstra wrote: > > On Mon, 2008-08-04 at 19:57 +0200, Andrea Arcangeli wrote: > > > From: Andrea Arcangeli <andrea@qumranet.com> > > > > > > Lockdep can't recognize if spinlocks are at a different address. So > > > using trylock in a loop is one way to avoid lockdep to generate false > > > positives. After lockdep will be fixed this change can and should be > > > reverted. > > > > > > Signed-off-by: Andrea Arcangeli <andrea@qumranet.com> > > > > NAK, come-on, you didn't even bother to look at the available > > annotations.. > > Let's say when I hear prove-locking my instinct tells me to walk away > as fast as I can. I'll try to explain why I prefer the trylock loop > (which btw is the only one that will hide the lockdep false positives > here and I welcome you to fix it in another way, well another way that > comes to mind is to call __raw_spin_lock which I didn't do because I > don't like those lowlevel details in common code). > > So about prove-locking: > > 1) in production is disabled so when I get bugreports I've to grab > locking deadlock information as usual (sysrq+t/p or preferably > lkcd/kdump) > > 2) while coding it's useless as well because I don't need this thing > to debug and fix any deadlocks > > 3) this only finds bugs after the system is hung and I can fix it by > other means then
You're so wrong it not even funny. It reports about deadlocks before they happen. All it needs is to observe a lock order violation and it will report it. In order for the dead-lock to happen, you need to actually hit the violation concurrently with the normal order.
IOW, lockdep can even spot deadlocks on a non-preempt single cpu setup where they can never actually happen.
Furthermore, it does more than the simple lock deadlocks, it also takes IRQ state into account. So it can tell about hard or soft irq recursion deadlocks.
Having lockdep on while developing saves a lot of trouble - in fact it _has_ caught many real bugs before they could be introduced to mainline, ask Arjan who has supervised driver development.
Not only that, it caught plenty of real bugs in mainline as well as -rt. These days it appears to not catch many because the tree is in such good shape, but that is fully thanks to lockdep.
That is not to say it's perferct - lockdep certainly does have it limitations. But your portrail is very in-accurate.
| |