Date: Mon, 19 Nov 2001 14:29:10 +0300 (MSK) From: Maxim Konovalov <maxim@macomnet.ru> To: Terry Lambert <tlambert2@mindspring.com> 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: <20011119133336.B37219-100000@news1.macomnet.ru> In-Reply-To: <3BF5AC86.8A402C96@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Thank you Terry for your answer, I got your meaning. IMHO we can safely commit my patch meanwhile: http://news1.macomnet.ru/~maxim/p/kern_lockf.c.diff Committers? :-) On Fri, 16 Nov 2001, Terry Lambert wrote: > 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 > > -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru 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?20011119133336.B37219-100000>