>Number:         2855
>Category:       kern
>Synopsis:       deadlock when trying to mount a directory onto itself
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 17 11:05:01 1996
>Last-Modified:
>Originator:     Wolfgang Solfrank
>Organization:
NetBSD Hackers
>Release:        NetBSD-current 10/17/96
>Environment:
	
System: NetBSD august 1.2A NetBSD 1.2A (GENERIC) #23: Tue Oct 15 16:22:05 MET DST 1996
     ws@kurt:/home/NetBSD/kernel/NetBSD/sys/arch/powerpc/compile/GENERIC PowerPC

>Description:
	
Mount commands that need a device for the mount (mount_ffs, mount_msdos etc.),
when given a path for the device that goes via the directory to be mounted on,
will either deadlock or panic with "locking against myself" depending on
whether the kernel is compiled with or without option DIAGNOSTIC.

>How-To-Repeat:
	
Any user can do:
$ mkdir /tmp/xxx
$ mount /tmp/xxx /tmp/xxx

If the kernel is compiled with option DIAGNOSTIC, a panic will result.
Otherwise the command will hang as will any other commands involving /tmp/xxx.

>Fix:
	
Currently unknown.

However a short analysis reveals the following:

The problem is that the device of the mount is looked up with the directory
to be covered by the mount already locked.  During the lookup a lock is
needed on any vnode traversed.  To avoid the resulting deadlock, the vnode
of the directory to be covered needs to be unlocked.  This however requires
that all of the checks and actions on the vnode need to be repeated that
the filesystem independent code already made before calling the filesystem
dependent mount code (things like invalidating block buffers, checking
permissions, checking whether someone else did mount something here in the
meantine, etc.).
>Audit-Trail:
>Unformatted: