From owner-freebsd-hackers Fri Nov 16 16:16:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id A81CE37B416; Fri, 16 Nov 2001 16:16:25 -0800 (PST) Received: from dialup-209.244.106.83.dial1.sanjose1.level3.net ([209.244.106.83] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 164t9i-0007e3-00; Fri, 16 Nov 2001 16:16:22 -0800 Message-ID: <3BF5AC86.8A402C96@mindspring.com> Date: Fri, 16 Nov 2001 16:17:10 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Konovalov Cc: Alfred Perlstein , John Baldwin , hackers@FreeBSD.org Subject: Re: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd) References: <20011116113214.S13973-100000@news1.macomnet.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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