Any results?

Posted Jun 1, 2006 14:14 UTC (Thu) by arjan (subscriber, #36785)
In reply to: Any results? by man_ls
Parent article: The kernel lock validator

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)

to post comments

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. ;)