Here's my latest patch about this.
I've an issue with lock usage in bio(4):
there is a bio_lock, which is a kmutex_t to protect the internal structures
of bio(4). A disk driver (for example mfi(4)) will also have its own
lock to protect its structure; and will probably call bio_register()
and bio_unregister() with this lock held.
The callback from bio(4) to mfi(4) shall be called with bio_lock held, to
avoid having the entry removed from under its feets (it's not the
case right now, but as nothing calls bio_unregister() for now, it's
safe).
Now we could have this deadlock (theorically; because mfi doesn't have
a mfi_detach):
mfi_detach() takes the mfi mutex, and calls bio_unregister() which takes
  bio_lock.
bioioctl() takes bio_lock, and call backs in mfi(4) which will want to
  take the mfi mutex.

I'm not a multithread expert programmer. How is such case handled usually ?
I think mfi_detach() should take bio_lock itself, so it can take locks
in an order which can avoid the deadlock. Or the callback in mfi could
release bio_lock itself before trying to take the mfi mutex, but I can't
see how to avoid the race in which the mfi device could dissapear between
releasing bio_lock and taking the mfi mutex at this point. Any idea ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--