On Mon, 31 May 1999, Konrad Schroder wrote:

> Something's been bothering me about this (more than the hanging references
> issue I mentioned earlier), and I think I've realized what it is:
> null_lock used to be a pass-through---which would have much the same
> effect as what you're suggesting.  But it was changed to the current (also
> broken) state because of locking problems.
> 
> Consider this scenario (a variation of PR #777):
> 
> 	/dev/sd0a on /     type ffs
> 	/dev/sd0e on /usr  type ffs
> 	/usr/src  on /a    type null
> 	/usr/src  on /c    type null
> 
> Touch a file Makefile (vnode A) in /a, with lower vnode B in /usr.
> Then touch Makefile in /c (vnode C).  Now both A and C have the same
> lower vnode.  This is fine, unless during the creation of C,
> the vnode that getnewvnode() finds to make it is A.  Then you either
> have:

Is vnode A still in use? If so, then getnewvnode can't find vnode A. If A
is not in use, we won't have a problem - see below.

> 	VOP_LOCK(A)  (in vgone: also locks B)
> 	VOP_LOCK(B)  (in null_node_create: panic, oops)
> or
> 	VOP_LOCK(B)
> 	VOP_LOCK(A)  (also locks B, panic, oops)
> or
> 	VOP_LOCK(A)
> 	(don't lock B ... bad idea)
> 
> None of which are really what you want.  A workaround might be to
> implement the unified lock as a semaphore, and manipulate the semaphore
> rather than panicking if it is "locking against myself"...but I'm not
> sure that squashing the "locking against myself" diagnostic message is
> such a good idea either.
> 
> Hope this was more coherent than my last message on this subject....

My thought was that when a vnode comes off of the free list, its struct
lock * (v_vnlock) is initialized to point to its struct lock (v_lock).
Thus an attempt to lock the pulled-from-freelist vnode will only lock that
node, not any other assosciated vnode.

Does that address your concerns?

Take care,

Bill