Re: panic: lockmgr: locking against myself

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi!
:
:Got this panic while running "darcs whatsnew" on a directory that was
:rsynced to/from a linux machine. Got the same crash after reboot and
:...
:#3  0xc03111f0 in lockmgr (lkp=0xe061cb20, flags=2) at /usr/src/sys/kern/kern_lock.c:348
:#4  0xc0376341 in vn_lock (vp=0xe061ca68, flags=2) at /usr/src/sys/kern/vfs_vnops.c:1002
:#5  0xc036e70c in vget (vp=0xe061ca68, flags=0) at /usr/src/sys/kern/vfs_lock.c:358
:#6  0xc0493963 in hammer_get_vnode (ip=0xe7d09450, vpp=0xde2b79c0) at /usr/src/sys/vfs/hammer/hammer_inode.c:320
:#7  0xc04a7b60 in hammer_vop_nresolve (ap=0xde2b7ad0) at /usr/src/sys/vfs/hammer/hammer_vnops.c:1126
:#8  0xc0377e48 in vop_nresolve_ap (ap=0xde2b7ad0) at /usr/src/sys/kern/vfs_vopops.c:1618
:#9  0xddaea05e in ?? ()
:#10 0xc0377b72 in vop_nresolve (ops=0xd9601bf0, nch=0xde2b7b10, dvp=0xe13a8068, cred=0xc3e27a08) at /usr/src/sys/kern/vfs_vopops.c:951
:#11 0xc036234b in cache_resolve (nch=0xde2b7b4c, cred=0xc3e27a08) at /usr/src/sys/kern/vfs_cache.c:2135
:#12 0xc036aa39 in nlookup (nd=0xde2b7c48) at /usr/src/sys/kern/vfs_nlookup.c:499
:#13 0xc03736e4 in kern_link (nd=0xde2b7c80, linknd=0xde2b7c48) at /usr/src/sys/kern/vfs_syscalls.c:2085
:#14 0xc037383f in sys_link (uap=0xde2b7cf0) at /usr/src/sys/kern/vfs_syscalls.c:2121
:#15 0xc053cc09 in syscall2 (frame=0xde2b7d40) at /usr/src/sys/platform/pc32/i386/trap.c:1339
:#16 0xc0526f06 in Xint0x80_syscall () at /usr/src/sys/platform/pc32/i386/exception.s:876
:#17 0x28782c03 in ?? ()
:Backtrace stopped: previous frame inner to this frame (corrupt stack?)
:
:I am running i386 DragonFly v2.4.1.28.gf85b4 on an AMD Athlon(tm) 64
:X2 Dual Core Processor 4400+
:
:I have now a similar situation inside a vkernel, but I am still not
:sure, what it really needs to get this panic. Looking at the vkernel
:...
:Is there a possibility to get a system call trace of the darcs process
:before the panic? Using ktrace I see no trace file after reboot.
:
:I am also currently not able to save a crash dump for the vkernel:
:Checking for core dump...
:savecore: read: Invalid argument
:Need to recheck my setup.
:...
:But maybe this information already triggers an idea... and I do not
:need to further dig into bits I do not understand.

    Crash dumps from the vkernel are problematic.

    From the backtrace it looks like cockpit trouble in the code.
    I'm trying very hard not to allow vnode lock recursion w/ HAMMER's
    vnodes and this sometimes reveals issues that would otherwise be masked.

    I suspect what is happening here is that an attempt is being made to
    create a hardlink from file A to file B where both files already exist
    and already point to the same inode.  The panic is only possible if
    file B is not already in the namecache.  When HAMMER is asked to lookup
    file B it temporarily locks the vnode which causes the panic because
    kern_link() is already holding A locked.

    Please try this patch.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c
index b8f19f3..4862ddd 100644
--- a/sys/kern/vfs_syscalls.c
+++ b/sys/kern/vfs_syscalls.c
@@ -2100,16 +2100,21 @@ kern_link(struct nlookupdata *nd, struct nlookupdata *linknd)
 	KKASSERT(nd->nl_flags & NLC_NCPISLOCKED);
 	nd->nl_flags &= ~NLC_NCPISLOCKED;
 	cache_unlock(&nd->nl_nch);
+	vn_unlock(vp);
 
 	linknd->nl_flags |= NLC_CREATE | NLC_REFDVP;
 	if ((error = nlookup(linknd)) != 0) {
-		vput(vp);
+		vrele(vp);
 		return (error);
 	}
 	if (linknd->nl_nch.ncp->nc_vp) {
-		vput(vp);
+		vrele(vp);
 		return (EEXIST);
 	}
+	if ((error = vn_lock(vp, LK_EXCLUSIVE | LK_RETRY)) != 0) {
+		vrele(vp);
+		return (error);
+	}
 
 	/*
 	 * Finally run the new API VOP.