kern/42737: sbp temporary detachment feature causes deadlocks

[Taylor R Campbell <campbell%mumble.net@localhost>]

>Number:         42737
>Category:       kern
>Synopsis:       sbp temporary detachment feature causes deadlocks
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 04 05:25:00 +0000 2010
>Originator:     Taylor R Campbell <campbell%mumble.net@localhost>
>Release:        NetBSD 5.0_STABLE
>Organization:
>Environment:
NetBSD ... 5.0_STABLE NetBSD 5.0_STABLE (APPLE_UFS_EI) #2: Fri Jul 31 20:44:51 
UTC 2009  riastradh@... i386
Architecture: i386
Machine: i386
>Description:

        Several days ago, I plugged a FireWire device (specifically, a
        MacBook with a hosed disk, booted into target disk mode) into
        a machine running NetBSD 5.0_STABLE.  I performed various
        diagnostics upon it, and mounted some some file systems from
        it using RUMP, which I fully unmounted before unplugging the
        device.  I did not run `fwctl -r' after unplugging the device,
        however, which apparently one is supposed to do.

        Today, I noticed that I hadn't gotten daily and security
        reports from that machine, which turns out to be because the
        processes generating them are waiting for `disklabel sd0',
        which is hung on a mutex.  I tried running `file -s /dev/sd0a'
        which hung too, unkillably.

        My kernel is configured just like GENERIC with the following
        two options added:

options         FFS_EI          # FFS Endian Independent support
options         APPLE_UFS       # Apple UFS support in FFS

        Whether or not I ought to have run `fwctl -r' after unplugging
        the device, NetBSD shouldn't wedge up like this.

>How-To-Repeat:

        I have not yet attempted to reproduce this; I shall do so once
        I have built a kernel with LOCKDEBUG enabled in order to
        diagnose the problem better in case I can reproduce it.

>Fix:

        I do not yet have a fix, but shall endeavour to seek one once
        I can reproduce the problem and debug the kernel symbolically.