kern/129053: lock order reversal
Brad Huntting
huntting at glarp.com
Fri Nov 21 08:40:02 PST 2008
>Number: 129053
>Category: kern
>Synopsis: lock order reversal
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Nov 21 16:40:02 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Brad Huntting
>Release: 7.1-PRERELEASE
>Organization:
>Environment:
FreeBSD spork.glarp.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Thu Nov 13 11:34:12 MST 2008 root at spork.glarp.com:/usr/src/sys/i386/compile/SPORK i386
>Description:
My device driver (a proprietary USB device called 'scmicro') appears to have tickled a lock order reversal. When witness.watch is enabled, all goes well until my driver detach()es. At which point my system panics with:
lock order reversal:
1st 0xc0c932a0 syscons video lock (syscons video lock) @ dev/syscons/syscons.c:2534
2nd 0xc0c23400 sched lock 0 (sched lock) @ kern/kern_clock.c:286
panic: blockable sleep lock (sleep mutex) sellck @ kern/sys_generic.c:1127
My driver creates two taskqueue(9) threads in attach() and destroys them in detach(). It has 4 mutexes which it uses to protect it's own data structures. In addition, it holds Giant around any code section which calls usb functions. With the exception of wakeup(9), cv_signal(9), cv_destroy(9) and taskqueue_enqueue_fast(), it always release it's own locks (except for Giant) before it calls external code.
Of course, this does not happen when my devices uses the ugen(4) driver.
Is this a known issue? Am I doing something wrong?
>How-To-Repeat:
Sorry, my client wont let me release details of the driver.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list