kern/73295: Lock order reversal in USB code.
Frank Mayhar
frank at lap.exit.com
Fri Oct 29 15:40:37 PDT 2004
>Number: 73295
>Category: kern
>Synopsis: Lock order reversal in USB code.
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Oct 29 22:40:29 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator: Frank Mayhar
>Release: FreeBSD 5.3-STABLE i386
>Organization:
Exit Consulting
>Environment:
System: FreeBSD lap 5.3-STABLE FreeBSD 5.3-STABLE #6: Wed Oct 27 18:08:57 PDT 2004 frank at lap:/home/obj/usr/src/sys/AUTON i386
This is with a kernel built with INVARIANTS, WITNESS and DIAGNOSTIC.
I just plugged in the USB device (a SanDisk CF reader) and got the
LOR:
usb3: handing over full speed device on port 3 to usb1
uhub3: port 3, device disappeared after reset
usb3: handing over full speed device on port 3 to usb1
uhub3: port 3, device disappeared after reset
umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2
umass0: Get Max Lun not supported (STALLED)
malloc(M_WAITOK) of "1024", forcing M_NOWAIT with the following non-sleepable locks held:
exclusive sleep mutex dont_sleep_in_callout r = 0 (0xc06c90c0) locked @ /usr/src/sys/kern/kern_timeout.c:257
KDB: enter: witness_warn
[thread 100032]
Stopped at kdb_enter+0x2b: nop
db> trace
kdb_enter(c0642e36) at kdb_enter+0x2b
witness_warn(5,0,c06788ac,c066347d,c0665fbd) at witness_warn+0x181
uma_zalloc_arg(c1433b00,0,2) at uma_zalloc_arg+0x41
malloc(260,c0693360,2,101,0) at malloc+0xb2
umass_cam_rescan(c218eb00,c06c90c0,0,c0665fbd,101) at umass_cam_rescan+0x1c
softclock(0) at softclock+0x1af
ithread_loop(c1d8fc80,d55e8d48,c1d8fc80,c04e6160,0) at ithread_loop+0x124
fork_exit(c04e6160,c1d8fc80,d55e8d48) at fork_exit+0xa4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd55e8d7c, ebp = 0 ---
It's pretty clear that umass_cam_rescan should be calling malloc with M_NOWAIT
rather than M_WAITOK (and, of course, handling the potential error return), or
alternatively that the rescan should happen in a sleepable context.
>Description:
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list