:The addition of the SOFTLOCKLEAF code is quite a major change, so
:it would be very useful if you could describe exactly what it does,
:what its semantics are, and how it fits into the rename problem.
Setting SOFTLOCKLEAF in namei will set the VSOFTLOCK flag in the
returned vnode (whether the returned vnode is locked or not), and
namei() will fail with EAGAIN if the VSOFTLOCK flag is already set.
An extra reference is added to the returned vnode which either
the caller must free or NDFREE must free (note that VOP_RENAME is
not responsible for freeing this extra reference, so the API itself
does not actually change). The caller must either call vclearsoftlock()
or call NDFREE() with the appropriate flags to clear the flag and
dereference the vnode.
int gc = 0;
vagain(&gc);
vagain() is a routine that falls through the first time, initializing
'gc' to a global counter. If later on you get an EAGAIN from a
SOFTLOCK failure and loop back up to the vagain(), it will block the
process until whomever owns the softlock has 'probably' released it.
This allows the system call to restart internally and attempt the
operation again from scratch.
:Because the source node and parent are not locked, there is the
:possibility that the source node could be renamed or removed at
:any time before VOP_RENAME finally gets around to locking it and
:removing it. Something needs to protect the source node against
:being renamed/removed between the point that the source node is
:initially looked up and the point that it is finally locked. Both
:Matt's SOFTLOCKLEAF and the VRENAME flag are there to provide this
:protection.
:
:It is the fact that this problem is entirely unique to VOP_RENAME
:that leads me to think that adding the generic SOFTLOCKLEAF code
:is overkill. The following fragment also suggests that maybe the
:approach doesn't actually fit in that well:
Well, maybe. I have my eye on possibly seeing a way to fix
the race-to-root directory scanning program too, so I decided
to implement VSOFTLOCK formally rather then as a hack.
:The way that vclearsoftlock() is used to clear a flag in an unlocked
:vnode is also not ideal. This should probably be protected at least
:by v_interlock as other flags are.
:
:Ian
In -current, definitely. I'm not sure why v_interlock even exists
in -stable.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
