[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: VOP_*LOCK* cleanup proposal
On Tue, Jun 22, 2010 at 10:27:13AM +0200, Juergen Hannken-Illjes wrote:
> The vnode lock operations still carry some arguments and semantics from
> our old lockmgr(9). I propose to clean them up as:
> 1) VOP_LOCK(vp, flags): Limit the set of allowed flags to LK_EXCLUSIVE,
> LK_SHARED and LK_NOWAIT. LK_INTERLOCK is no longer allowed as it
> makes no sense here.
> 2) VOP_UNLOCK(vp, flags): Remove the flags argument. It must be zero
> for some time now.
> 3) VOP_ISLOCKED(vp): Remove the for some time unused return value
> LK_EXCLOTHER. Mark this operation as "diagnostic only". Making a
> lock decision based on this operation is no longer allowed.
> A diff covering 1) and 3) is attached. The result of the substitution
> 's/\(VOP_UNLOCK([^,]*\), 0/\1/' to kill the second argument of
> VOP_UNLOCK() is omitted as it is completely mechanic.
> Comments or objections anyone?
Go for it. I looked into similar changes before but got sidetracked.
There is another closely related item. Strictly speaking, vget() should
never be called without holding v_interlock. I had a scan of the places
we are not specifying LK_INTERLOCK and they fall into two categories:
- Should be using v_interlock + vget() but is racy. vnode can be
reincarnated with a different identity, or freed or...
- Abusing vget() to mean vref() + VOP_LOCK(). At these points the
vnode's identity isn't going to change, so vget() isn't appropriate.
Main Index |
Thread Index |