Re: panic: share -> excl _at_r224632

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Thu, 4 Aug 2011 16:59:32 +0300
On Thu, Aug 04, 2011 at 05:54:54AM -0700, David Wolfskill wrote:
> I've only seen this on my laptop; my build machine doesn't exhibit the
> panic.
> 
> r224602 is the most recent point I've built that does not exhibit the
> panic at all.
> 
> The first few lines (hand-transcribed; I have no serial console on this
> laptop -- the one shortcoming it has):
> 
> shared lock of (lockmgr) devfs _at_/usr/src/sys/kern/vfs_cache.c:1116
> while exclusively locked from /usr/src/sys/kern/vfs_subr.c:2134
> panic: share -> excl
> 
> The backtrace (which I wasn't patient enough to trto transcribe twice;
> sorry) appeared to involve "nmount", and the panic occurred directly
> after mounting the file systems during the transition from single-user
> mode to multi-user mode.
> 
> The output from "svn update" going from r224602 -> r224632 shows the
> following files being updated:
> 
> U    usr.sbin/faithd/faithd.8
> U    usr.sbin/jail/jail.8
> U    lib/libproc/proc_create.c
> U    sys/arm/arm/irq_dispatch.S
> U    sys/arm/sa11x0/sa11x0_irq.S
> U    sys/powerpc/booke/locore.S
> U    sys/powerpc/booke/platform_bare.c
> U    sys/powerpc/booke/pmap.c
> U    sys/nfsclient/nfsnode.h
> U    sys/nfsclient/nfs_node.c
> U    sys/kern/kern_jail.c
> U    sys/kern/vfs_mount.c
> U    sys/fs/nfsclient/nfsnode.h
> U    sys/fs/nfsclient/nfs_clnode.c
> U    sys/mips/mips/exception.S
> U    sys/dev/ahci/ahci.c
> U    sys/dev/ata/chipsets/ata-nvidia.c
> U    sys/dev/ath/ath_hal/ah_eeprom_v4k.c
> U    sys/i386/ibcs2/imgact_coff.c
> U    sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
> Updated to revision 224632.
> 
> Updating to r224648 (this morning) has had no apparent effect on the
> cited panic: it occurs in the same way, at the same time, accompanied by
> the same messages (citing the same files and lines).
> 
> I've attached dmesg.boot from r224602.
> 
> I will see if I can find a commit that affected at least one of the
> affected files in the above list that I can revert to avoid the panic,
> but I'm a bit slow for a while yet, so I figured I'd finally get around
> to posting this, in the hope that someone cleverer than me will spot
> the problem and suggest a circumvention to try.
> 
> And I'm quite willing to try such things.
> 
> Note: this is FreeBSD/i386; nothing special: no jails; running on real
> hardware; no attempts to use ZFS....
I am sure that this is caused by r224614.
I forgot that vn_fullpath cannot operate on the locked vnode.

Try this.

diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index d601c56..54f123c 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
_at__at_ -746,13 +746,15 _at__at_ vfs_domount_first(
 	struct thread *td,		/* Calling thread. */
 	struct vfsconf *vfsp,		/* File system type. */
 	struct vnode *vp,		/* Vnode to be covered. */
+	char *ufspath,
 	int fsflags,			/* Flags common to all filesystems. */
 	struct vfsoptlist **optlist	/* Options local to the filesystem. */
 	)
 {
 	struct vattr va;
+	struct nameidata nd;
 	struct mount *mp;
-	struct vnode *newdp;
+	struct vnode *newdp, *vp1;
 	char *fspath, *fbuf;
 	int error;
 
_at__at_ -761,16 +763,45 _at__at_ vfs_domount_first(
 	KASSERT((fsflags & MNT_UPDATE) == 0, ("MNT_UPDATE shouldn't be here"));
 
 	/* Construct global filesystem path from vp. */
+	VOP_UNLOCK(vp, 0);
 	error = vn_fullpath_global(td, vp, &fspath, &fbuf);
 	if (error != 0) {
-		vput(vp);
+		vrele(vp);
 		return (error);
 	}
 	if (strlen(fspath) >= MNAMELEN) {
-		vput(vp);
+		vrele(vp);
 		free(fbuf, M_TEMP);
 		return (ENAMETOOLONG);
 	}
+	if ((vp->v_iflag & VI_DOOMED) != 0) {
+		vrele(vp);
+		free(fbuf, M_TEMP);
+		return (EBADF);
+	}
+
+	/*
+	 * Re-lookup the vnode by path. As a side effect, the vnode is
+	 * relocked.  If vnode was renamed, return ENOENT.
+	 */
+	NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | MPSAFE | AUDITVNODE1,
+	    UIO_SYSSPACE, ufspath, td);
+	error = namei(&nd);
+	if (error != 0) {
+		vrele(vp);
+		free(fbuf, M_TEMP);
+		return (error);
+	}
+	if (NDHASGIANT(&nd))
+		mtx_unlock(&Giant);
+	NDFREE(&nd, NDF_ONLY_PNBUF);
+	vp1 = nd.ni_vp;
+	vrele(vp);
+	if (vp1 != vp) {
+		vput(vp1);
+		free(fbuf, M_TEMP);
+		return (ENOENT);
+	}
 
 	/*
 	 * If the user is not root, ensure that they own the directory
_at__at_ -1084,14 +1115,11 _at__at_ vfs_domount(
 	NDFREE(&nd, NDF_ONLY_PNBUF);
 	vp = nd.ni_vp;
 	if ((fsflags & MNT_UPDATE) == 0)
-		error = vfs_domount_first(td, vfsp, vp, fsflags, optlist);
+		error = vfs_domount_first(td, vfsp, vp, fspath, fsflags, optlist);
 	else
 		error = vfs_domount_update(td, vp, fsflags, optlist);
 	mtx_unlock(&Giant);
 
-	ASSERT_VI_UNLOCKED(vp, __func__);
-	ASSERT_VOP_UNLOCKED(vp, __func__);
-
 	return (error);
 }
 

Received on Thu Aug 04 2011 - 11:59:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC