>Number:         31382
>Category:       kern
>Synopsis:       unionfs causes panic during unmount in insmntque
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 23 21:33:00 +0000 2005
>Originator:     jmmv@netbsd.org
>Release:        NetBSD 3.99.8
>Organization:
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/
>Environment:
	
	
System: NetBSD dawn.home.network 3.99.8 NetBSD 3.99.8 (DAWN) #: Sat Sep 10 18:46:38 CEST 2005 jmmv@dawn.home.network:/o/s/src/sys/arch/i386/compile/DAWN i386
Architecture: i386
Machine: i386
>Description:
	Given the following mount layout and a kernel built with DIAGNOSTIC:

		In fstab:
		/dev/wd0a / ffs rw 1 1
		tmpfs /tmpfs tmpfs rw
		/bin /mnt/test union rw,-b

		Shown by mount:
		/dev/wd0a on / type ffs (local)
		tmpfs on /tmpfs type tmpfs (NFS exported, local)
		<below>:/bin on /mnt/root type union

	the system panics during a shutdown with a "insmntque into dying
	filesystem" message if there has been somewhat "intensive" activity
	on the root file system.  This message appears while unmounting the
	union file system (/mnt/test).

	In order to do the unmount, the kernel calls VFS_ROOT over the
	unionfs mount point to get a vnode for that directory.  That in turn
	calls unionfs_root, which then calls unionfs_allocvp.  This last
	routine does a getnewvnode with a VT_UNION tag.

	Then, getnewvnode calls insmntque, which does a strange check:
	it panics if the file system is being unmounted, it does not use
	soft dependencies and the vnode's tag is different than VT_VFS.
	Here, the tag is VT_UNION which clearly does not match VT_VFS, so
	the panic is raised.  I don't know the meaning of this diagnostic
	check, so I don't know what a correct solution could be.
>How-To-Repeat:
	Create a /mnt/test directory and mount a unionfs on it:

	mount -t union -o -b /bin /mnt/test

	Then, go to the root directory and do some operations on disk.
	Unpacking base.tgz is enough for me to expose the problem.

	At last, reboot and watch for the panic while the file systems
	are unmounted.
>Fix:
	Don't know.  I've applied the following patch which has hidden the
	problem, but I highly doubt this is a real fix.

Index: fs/union/union_subr.c
===================================================================
RCS file: /cvsroot/src/sys/fs/union/union_subr.c,v
retrieving revision 1.14
diff -u -r1.14 union_subr.c
--- fs/union/union_subr.c	30 Aug 2005 19:11:43 -0000	1.14
+++ fs/union/union_subr.c	23 Sep 2005 21:17:57 -0000
@@ -513,7 +513,8 @@
 			goto loop;
 	}
 
-	error = getnewvnode(VT_UNION, mp, union_vnodeop_p, vpp);
+	error = getnewvnode((mp->mnt_iflag & IMNT_UNMOUNT) ? VT_VFS : VT_UNION,
+	    mp, union_vnodeop_p, vpp);
 	if (error) {
 		if (uppervp) {
 			if (dvp == uppervp)

>Unformatted: