Re: getblk(): panic: lockmgr: locking against myself

Hi,

This looks like a ufs2 snapshot bug when initializing more
inodes in a cylinder group.
bawrite for newly initialized inode block is called while the thread
still owns the cylinder group block.
The snapshot copy-on-write code tries to save the old (uninitialized)
block and might need the cg block to do so => panic.

Not saving the uninitialized inode block does not look like an
option as inode access functions do not check the cg for cg_initediblk.

The ugly patch below calls the bawrite for the inode block after
it releases (bdwrites) the cg block and should prevent the panic.

Take the above with a grain of salt as I don't have much personal interest
in ffs2/ffs snapshot code.
 
	Stephan


--- ffs_alloc.c Wed Jun 11 02:31:28 2003
+++ ffs_alloc.c_patched Sat Dec 20 20:54:23 2003
_at__at_ -1634,12 +1634,18 _at__at_
                        dp2->di_gen = arc4random() / 2 + 1;
                        dp2++;
                }
-               bawrite(ibp);
                cgp->cg_initediblk += INOPB(fs);
+       } else {
+         ibp = NULL;
        }
+
        if (fs->fs_active != 0)
                atomic_clear_int(&ACTIVECGNUM(fs, cg), ACTIVECGOFF(cg));
        bdwrite(bp);
+
+       if (ibp)
+         bawrite(ibp);
+
        return (cg * fs->fs_ipg + ipref);
 }

 
> 
> This is using Sam's netperf+sockets branch, but the problem doesn't
> actually appear to be his fault :-).  The box is dual-processor with 1gb
> of memory, local scsi disks used for the build.  Given the lack of network
> activity and trace, I think it's more likely to be a problem with -CURRENT
> than a result of the local network locking changes.
> 
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research
> 
> login: panic: lockmgr: locking against myself
> cpuid = 0; 
> Debugger("panic")
> Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
> db> trace
> Debugger(c0851c3c,0,c0850715,e81e934c,100) at Debugger+0x55
> panic(c0850715,0,c08506db,e7,c6e0a8c0) at panic+0x156
> lockmgr(d31de934,2090022,c6c40678,c6e0a8c0,69726373) at lockmgr+0x49e
> getblk(c6c40678,44ea40,0,4000,0) at getblk+0x170
> breadn(c6c40678,44ea40,0,4000,0) at breadn+0x52
> bread(c6c40678,44ea40,0,4000,0) at bread+0x4c
> ffs_alloccg(c6c3f9d8,c,113a68,0,4000) at ffs_alloccg+0xec
> ffs_hashalloc(c6c3f9d8,c,113a68,0,4000) at ffs_hashalloc+0x37
> ffs_alloc(c6c3f9d8,2275e,0,113a68,0) at ffs_alloc+0x1b7
> ffs_balloc_ufs2(c6c40450,89d78000,0,4000,c29a1200) at
> ffs_balloc_ufs2+0x181e
> ffs_copyonwrite(c6c40678,d328a820,c0683350,c6c2c128,0) at
> ffs_copyonwrite+0x3c5
> spec_xstrategy(c6c40678,d328a820,e81e9768,c0600cb8,e81e9794) at
> spec_xstrategy+0
> x112
> spec_specstrategy(e81e9794,e81e97b4,c067e894,e81e9794,1) at
> spec_specstrategy+0x
> 1b
> spec_vnoperate(e81e9794,1,c0855664,360,e81e97a8) at spec_vnoperate+0x18
> bwrite(d328a820,e81e9840,c076d0fe,d328a820,4000) at bwrite+0x424
> bawrite(d328a820,4000,0,4000,0) at bawrite+0x1c
> ffs_nodealloccg(c70c5230,c,45259,0,81a4) at ffs_nodealloccg+0x55e
> ffs_hashalloc(c70c5230,c,45259,0,81a4) at ffs_hashalloc+0x37
> ffs_valloc(c70c0000,81a4,c6e29c80,e81e98dc,3e8) at ffs_valloc+0xce
> ufs_makeinode(81a4,c70c0000,e81e9bf0,e81e9c04,602) at ufs_makeinode+0x69
> ufs_create(e81e9a64,e81e9b20,c069b9ae,e81e9a64,e81e9a60) at
> ufs_create+0x39
> ufs_vnoperate(e81e9a64,e81e9a60,2,100,c6e0a8c0) at ufs_vnoperate+0x18
> vn_open_cred(e81e9bdc,e81e9cdc,1a4,c6e29c80,3) at vn_open_cred+0x19e
> vn_open(e81e9bdc,e81e9cdc,1a4,3,c72d8378) at vn_open+0x33
> kern_open(c6e0a8c0,806b6e4,0,602,1b6) at kern_open+0xce
> open(c6e0a8c0,e81e9d14,c086ae1c,3ee,3) at open+0x30
> syscall(2f,2f,2f,806b6e4,1) at syscall+0x2a0
> Xint0x80_syscall() at Xint0x80_syscall+0x1d