Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Mar 1998 16:35:31 -0600
From:      Karl Denninger  <karl@mcs.net>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Odd problem we're seeing here
Message-ID:  <19980315163531.12987@mcs.net>
In-Reply-To: <199803152212.PAA14399@usr06.primenet.com>; from Terry Lambert on Sun, Mar 15, 1998 at 10:12:59PM %2B0000
References:  <199803152155.OAA13550@usr06.primenet.com> <199803152212.PAA14399@usr06.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I don't understand something.

Why not, when you release a lock on a file mounted over NFS, just flush the
cached attributes BEFORE you release the lock at the kernel level?

No, it doesn't take care of the case where you don't lock.  But it DOES
solve the problem where you do (and if you're not locking, you arguably
deserve what you get anyway).

--
-- 
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly / All Lines K56Flex/DOV
			     | NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

On Sun, Mar 15, 1998 at 10:12:59PM +0000, Terry Lambert wrote:
> > 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?19980315163531.12987>