Any results?

Posted Jun 1, 2006 6:32 UTC (Thu) by man_ls (guest, #15091)
Parent article: The kernel lock validator

I'm surprised that nobody has asked this before. Solutions that look well in theory are, well, just theoretical; but does it work in practice? I assume that someone, at least the author, has had it running for some time now. How does it behave? Has anyone found potential deadlocks on running code, already? Otherwise, are there too few results, too many false positives?

Any results?

Posted Jun 1, 2006 14:14 UTC (Thu) by arjan (subscriber, #36785) [Link] (3 responses)

the ratio of "false positive" and real bugs is about 1:1 so far, where the false positives generally are doing some fishy-but-happens-to-be-ok locking most of the time. The false positives generally require more instrumentation in the code for the exact locking rules, which is good for documentation purposes anyway

I've lost track but we're well over the count of 20 with real bugs found so far (several of these got fixed in mainline before lockdep got posted the other day so it's a bit hard to count)

Any results?

Posted Jun 2, 2006 0:33 UTC (Fri) by linportal (guest, #38148) [Link] (1 responses)

What I have missed in all this is the address to forward detected bugs to. What about this one: kseriod deadlock? Is it real or false positive?

Any results?

Posted Jun 3, 2006 11:59 UTC (Sat) by mingo (subscriber, #31122) [Link]

That's a false positive, caused by recursive locking in the serio code. Arjan has posted the fix:

--- linux/drivers/input/serio/libps2.c.orig
+++ linux/drivers/input/serio/libps2.c
@@ -177,7 +177,7 @@ int ps2_command(struct ps2dev *ps2dev, u
                return -1;
        }

-       mutex_lock(&ps2dev->cmd_mutex);
+       mutex_lock_nested(&ps2dev->cmd_mutex, SINGLE_DEPTH_NESTING);

        serio_pause_rx(ps2dev->serio);
        ps2dev->flags = command == PS2_CMD_GETID ? PS2_FLAG_WAITID : 0;

Any results?

Posted Jun 4, 2006 3:54 UTC (Sun) by nevets (subscriber, #11875) [Link]

the ratio of "false positive" and real bugs is about 1:1 so far, where the false positives generally are doing some fishy-but-happens-to-be-ok locking most of the time.

And as Ingo already pointed out. The fishy-but-happens-to-be-ok are now nicely documented by the work arounds to (in akpm's words) make-lockdep-shut-up patches. ;)