Subject: Re: mount_null: /mnt (/mnt) and /mnt are not distinct paths
To: Bill Sommerfeld <wes@thunk.epilogue.com>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: tech-kern
Date: 06/30/1999 13:15:36
On Wed, 30 Jun 1999, Bill Sommerfeld wrote:

> One reason for this restriction is to avoid deadlocks.
> (this limit really should be enforced by the kernel; now that we have
> vn_isunder(), as a side effect of my sys___getcwd() implementation, it
> can be..)
> 
> You need to impose an ordering between any pair of vnodes which may be
> locked at the same time by the same process; the ordering used by
> BSD4.4 VFS is that if Y is a vnode in a subdirectory of X, X must
> always be locked before Y.
> 
> if you have:
> 	mount -t null /mnt  /mnt/xxx/yyy
> 
> Then, given the new pass-through locking scheme implemented by the
> other Bill S., if two processes both try to look up /mnt/xxx/yyy, you
> may deadlock:

VERY good point. :-)

While I agree with your analysis whole heartedly, the locking changes I
made are orthogonal here. :-)

With /mnt/xxx/yyy being over /mnt, the current nullfs code will do a
genfs_nolock on the null node at /mnt/xxx/yyy, and then try to do a
VOP_LOCK on the underlying node, /mnt. As every leaf fs except ntfs and
nfs do real lockmgr locking, we'd still get the deadlock.

> 	process A:
> 		lock /mnt
> 		lock /mnt/xxx
> 		unlock /mnt
> 		<blocks doing I/O reading the /mnt/xxx directory>
> 
> 	process B:
> 		lock /mnt
> 		BLOCK waiting for lock on /mnt/xxx held by A
> 
> 	process A:
> 		BLOCK waiting for lock on /mnt/xxx/yyy, AKA /mnt, held
> 			by B

Take care,

Bill