The following reply was made to PR kern/37191; it has been noted by GNATS.

From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@NetBSD.org
Cc: ad@netbsd.org
Subject: Re: kern/37191: softdep: locking against myself
Date: Wed, 24 Oct 2007 12:36:43 +0300

 On Wed Oct 24 2007 at 08:10:00 +0000, ad@netbsd.org wrote:
 > 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.
 
 This is kind of the same problem that puffs has if the file server makes a
 system call which tries to clean a puffs vnode for the same file system.
 There I am just very careful not to do blocking operations if VXLOCK
 is set.  That would obviously not work here.
 
 Anyway, we were discussing with Bill (not groo) about moving the whole
 vnode garbage collection to a separate context to prevent weird corner
 case deadlocks.
 
 -- 
 Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
 http://www.iki.fi/pooka/                          http://www.NetBSD.org/
     "la qualité la plus indispensable du cuisinier est l'exactitude"