Date: Fri, 16 Nov 2001 16:17:10 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Maxim Konovalov <maxim@macomnet.ru> Cc: Alfred Perlstein <bright@mu.org>, John Baldwin <jhb@FreeBSD.org>, hackers@FreeBSD.org Subject: Re: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd) Message-ID: <3BF5AC86.8A402C96@mindspring.com> References: <20011116113214.S13973-100000@news1.macomnet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxim Konovalov wrote:
> Alfred, John, thanks you very much for your answers. I expected
> something similar. Btw are there any smart ways to find out does
> underlying FS support inode concept or not? Yes, I know about
> vnode.v_tag, but comparing it with VT_UFS/VT_NFS/VT_MFS etc does not
> look OK for me.
In theory, vnodes are supposed to be opaque types, with no backing
object exposure.
The real problem here is that the lock list should not be hung
off the inode at all, it should be hung off the vnode, and the
underlying FS objects not referenced (as you noted, there's a
"two for one" object reference locking problem in the current
code). You still need to go to the backing FS, though, since
you need to proxy NFS client locks to remote objects, etc.. IF
you look at ufs_advlock(), you can see the problem:
ufs_advlock(ap)
struct vop_advlock_args /* {
struct vnode *a_vp;
caddr_t a_id;
int a_op;
struct flock *a_fl;
int a_flags;
} */ *ap;
{
register struct inode *ip = VTOI(ap->a_vp);
return (lf_advlock(ap, &(ip->i_lockf), ip->i_size));
}
... the vp lock has to imply an ip lock, at least for the i_lockf
list head, which is procedurally exposed.
A better fix would be to move the lock list into the vnode, and
then call the VOP_ADVLOCK() and assert the lock only if the VFS
VOP_ADVLOCK() returned true.
This really can't be done safely, since you need to addert locally
before remotely, but then you need to delay the local coelesce, or
you can screw up if the local succeeds and the remote fails, or
vice versa.
So the true fix has to include delayed coelescing of the local lock
assertion.
That's true anyway, since the NFSv4 specification demands that the
locks not be coelesced at all, for an implementation to be compliant.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BF5AC86.8A402C96>