Date: Fri, 6 Apr 2001 17:59:59 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: Matt Dillon <dillon@earth.backplane.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <Pine.NEB.3.96L.1010406175434.13782B-100000@fledge.watson.org> In-Reply-To: <200104050022.RAA02886@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Apr 2001, Terry Lambert wrote: > It's implicit in the fact that results caching is permitted; that means > that the results you get need to be valid for everyone. The only way to > assure this is to use a credential that can always get results. The > only alternative is not to cache. My reading of nfs_statfs() was that the results aren't cached in our implementation. Is this an incorrect interpretation? My hope was to preserve the real credentials wherever possible, avoiding arbitrarily constructing credentials. If a credential must be constructed without paying attention to the creation context, then it should be an NFS credential, not a normal subject credential. My understanding also is, BTW, that uid 0 is not required to be special for servers, and so the constructed credential may not even provide magic capabilities. > > I think you want to keep crget()/crfree() if possible, just so you > > don't have to worry about the data being sent over the wire breaking > > some poor sod. But if you want to bite the bullet and use the process > > ucred I'd say go for it - keep a careful watch for complaints of > > FreeBSD suddenly failing against various NFS servers though. > > Note that this means you must keep the processes from which you derive > the data around, so if you have a stalled call blocked on a server > reboot (for example), you cause a lot of problems. Again, I'm not sure I follow. Here's my reading of how the code currently works: instantiate a credential make the NFS RPC free the credential This isn't different, from a reference count perspective from make the NFS RPC with an existing credential In both cases, there a valid held reference to the credential on calling into the implementation, and it is valid for the durection of the function call. If the NFS implementation needs to preserve the credential, it will do so by bumping the reference count. However, a quick glance at the code doesn't make it clear to me that it even needs to do that. In any case, the validity of the reference is assured until the function exits, at which point both (today) and (soon) have the same behavior: the cred could potentially be released almost immediately. Sooner, in fact, with the crget/crfree, but the same race if the bug did exist. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010406175434.13782B-100000>