Subject: Re: vnode locking procedure change to suport stacked fs's.
To: Konrad Schroder <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/01/1999 11:35:12
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
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)
> VOP_LOCK(A) (also locks B, panic, oops)
> (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?