From owner-freebsd-hackers Sun Mar 15 14:13:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14033 for freebsd-hackers-outgoing; Sun, 15 Mar 1998 14:13:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14013 for ; Sun, 15 Mar 1998 14:13:05 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA08791; Sun, 15 Mar 1998 15:13:04 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd008762; Sun Mar 15 15:13:02 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA14399; Sun, 15 Mar 1998 15:12:59 -0700 (MST) From: Terry Lambert Message-Id: <199803152212.PAA14399@usr06.primenet.com> Subject: Re: Odd problem we're seeing here To: tlambert@primenet.com (Terry Lambert) Date: Sun, 15 Mar 1998 22:12:59 +0000 (GMT) Cc: karl@mcs.net, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199803152155.OAA13550@usr06.primenet.com> from "Terry Lambert" at Mar 15, 98 09:55:24 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If you look at the code around the vn_read and vn_write, vs. the > code around vn_rdwr, you will see a pattern begin to emerge. > > In all cases, when vn_read or vn_write is called, the vp is locked. I meant "unlocked". Right now, I am unsure of the lease code. When I say that I think the vp should be locked, that's because all vp's should be locked before they are dereferenced to make VOP calls. This is also why vp locking should be done with a vn_lock() function which locks the vp before it makes the VOP_LOCK call by dereferencing the vp to get the FS specific function. This is also why the underlying VOP_LOCK should be veto-based. Basically, if a vp is in the VOF layer (not necessarily just below the VFS layer, at least until Michael Hancock's VOP_VRELE), the vp should be locked. Period. This drastically simplifies a VFS consumer's view of the world. I do not think the lease code would actually survive being called with a locked vp at this point because of nqnfs_lease_updatetime, which traverses the mountlist. This is not something trivially fixable without a lot of controversial code. Hence the punt. Is that enough information? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message