Date: Sun, 15 Mar 1998 22:12:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tlambert@primenet.com (Terry Lambert) Cc: karl@mcs.net, tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Odd problem we're seeing here Message-ID: <199803152212.PAA14399@usr06.primenet.com> In-Reply-To: <199803152155.OAA13550@usr06.primenet.com> from "Terry Lambert" at Mar 15, 98 09:55:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803152212.PAA14399>