>Number:         37191
>Category:       kern
>Synopsis:       softdep: locking against myself
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 24 08:10:00 +0000 2007
>Originator:     Andrew Doran
>Release:        4.99.34
>Organization:
The NetBSD Project
>Environment:
N/A
>Description:
Locking against myself panic from softdep. This is with a kernel
from the vmlocking branch, but it probably also applies to HEAD:

panic: lockmgr: locking against myself (type *0* flags 400, sharecount 0, exclusivecount 1, recurselevel 0, waitcount 0, wmesg vnlock, lock_addr 0xc020632c, unlock_addr 0xc0206248)

Stopped in pid 20214.1 (nbconfig) at    netbsd:breakpoint+0x1:  ret
db{0}> bt
breakpoint(c04412b5,cc09f298,cc09f28c,c029fad7,30303498) at netbsd:breakpoint+0x1
panic(c043d038,cc09f35a,c043d432,cc09f2c4,0) at netbsd:panic+0xc1
lockmgr(cf8b7320,10002,cf8b728c,0,0) at netbsd:lockmgr+0x4c1
ffs_lock(cc09f49c,0,0,d83c9c40,0) at netbsd:ffs_lock+0xdc   
VOP_LOCK(cf8b728c,10002,c04d2760,c04b478c,cf8b728c) at netbsd:VOP_LOCK+0x7b
vn_lock(cf8b728c,10002,0,488aa,488aa) at netbsd:vn_lock+0x9c
vget(cf8b728c,10002,80,0,0) at netbsd:vget+0x1d2
ufs_ihashget(c,488aa,0,2,0) at netbsd:ufs_ihashget+0x94
ffs_vget(c1b74000,488aa,0,cc09f65c,d83c9c40) at netbsd:ffs_vget+0x42
softdep_sync_metadata(cdbc7358,cdbc7358,0,c02775ad,c04b5528) at netbsd:softdep_sync_metadata+0x440
ffs_full_fsync(cdbc7358,5,1,c027aa0b,100001) at netbsd:ffs_full_fsync+0x21d
ffs_fsync(cc09f794,0,cc09f7bc,c02df612,cc09f79c) at netbsd:ffs_fsync+0x67  
VOP_FSYNC(cdbc7358,ffffffff,5,0,0) at netbsd:VOP_FSYNC+0x9f
vinvalbuf(cdbc7358,1,ffffffff,d83c9c40,0) at netbsd:vinvalbuf+0xb6
vclean(cdbc7358,8,0,c027a1b4,0) at netbsd:vclean+0x163
getcleanvnode(c04d3b2c,200000,0,c02789b9,a7c0) at netbsd:getcleanvnode+0x143
getnewvnode(1,c1b74000,c1a38700,cc09f934,1f) at netbsd:getnewvnode+0xe4
ffs_vget(c1b74000,49ac5,0,cc09fbb8,c00) at netbsd:ffs_vget+0x72
ffs_valloc(cf8b728c,81a4,cad640c0,cc09fbb8,c1c4d604) at netbsd:ffs_valloc+0x5d3
ufs_makeinode(81a4,cf8b728c,cc09fbb8,cc09fbcc,cf8b728c) at netbsd:ufs_makeinode+0x71
ufs_create(cc09fab0,c02673a0,0,0,0) at netbsd:ufs_create+0x55
VOP_CREATE(cf8b728c,cc09fbb8,cc09fbcc,cc09fb00,0) at netbsd:VOP_CREATE+0x88
vn_open(cc09fba4,602,1a4,3,9c3c) at netbsd:vn_open+0x115
sys_open(d83c9c40,cc09fc50,cc09fc48,cc09fc80,c03167af) at netbsd:sys_open+0xba
syscall_plain() at netbsd:syscall_plain+0x134
--- syscall (number 5) ---

This is with kern.maxvnodes set to 2000. The newly created file
needs a vnode, so we reclaim an inactive one from ffs. That means
flushing any data + softdep dependencies from the vnode. It looks
like softdep is trying to push out a modification to the parent
directory (?) of the vnode which we are flushing. The directory is
already locked because the flush is the result of creating a file
in it.

>How-To-Repeat:
Exercise a file system with softdep enabled. Set kern.maxvnodes to a
value low enough to not make the test I/O bound, but enough to push up
the rate at which vnodes are recycled.


>Fix:
Journaling :-)