kern/39052: assertion "!ISSET(bp->b_cflags, BC_BUSY)" failed

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

>Number:         39052
>Category:       kern
>Synopsis:       assertion "!ISSET(bp->b_cflags, BC_BUSY)" failed
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 27 10:05:00 +0000 2008
>Originator:     Manuel Bouyer
>Release:        NetBSD 4.99.66
>Organization:
>Environment:
System: NetBSD admin3-dom0.lip6.fr 4.99.66 NetBSD 4.99.66 (XEN3_DOM0) #206: Thu 
Jun 26 12:20:20 CEST 2008 
bouyer@rock:/dsk/l1/misc/bouyer/tmp/amd64/obj/dsk/l1/misc/bouyer/current/src/sys/arch/amd64/compile/XEN3_DOM0
 amd64
Architecture: x86_64
Machine: amd64
>Description:
        This is a Xen dom0, with 2 linux domUs. The domU's virtual disks
        are backed by files in a FFS.
        The system reliably panics when running the daily scripts with:
panic: kernel diagnostic assertion "!ISSET(bp->b_cflags, BC_BUSY)" failed: file
/dsk/l1/misc/bouyer/current/src/sys/kern/vfs_bio.c", line 1320
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff804abc0d cs e030 rflags 246 cr2  7f7ffdfec000 cp0
Stopped in pid 2726.1 (find) at netbsd:breakpoint+0x5:  leave
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x255
__kernassert() at netbsd:__kernassert+0x2d
getnewbuf() at netbsd:getnewbuf+0x2c4
getblk() at netbsd:getblk+0x91
bio_doread() at netbsd:bio_doread+0x24
bread() at netbsd:bread+0x22
ffs_read() at netbsd:ffs_read+0x372
VOP_READ() at netbsd:VOP_READ+0x2d
ufs_readdir() at netbsd:ufs_readdir+0x10b
VOP_READDIR() at netbsd:VOP_READDIR+0x39
vn_readdir() at netbsd:vn_readdir+0x10e
sys___getdents30() at netbsd:sys___getdents30+0x89
syscall() at netbsd:syscall+0x98
(I've seen different variations of the stack trace, but it's always FFS doing
getblk()).
Michael van Elst suggested it could be related to locking issues in vnd,
but I don't have more details. Note that the xen backend block device
calls bdev_strategy() from interrupt context, I don't know if it
can have a bad effect. AFAIK, this will cal vndstrategy() which will
enqueue the buffer and wakeup a kernel thread to handle it. This shouldn't
interract at all with the buffer cache.

>How-To-Repeat:
        Run a dom0 with some (linux ?) domUs. Wait for the daily scripts        
        to fire.
>Fix: