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