Subject: Re: vnode locking procedure change to suport stacked fs's.
To: Bill Studenmund <email@example.com>
From: Konrad Schroder <firstname.lastname@example.org>
Date: 05/31/1999 15:00:30
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
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....