Date: Fri, 6 Apr 2001 23:08:31 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rwatson@FreeBSD.ORG (Robert Watson) Cc: tlambert@primenet.com (Terry Lambert), dillon@earth.backplane.com (Matt Dillon), freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <200104062308.QAA05544@usr01.primenet.com> In-Reply-To: <Pine.NEB.3.96L.1010406175434.13782B-100000@fledge.watson.org> from "Robert Watson" at Apr 06, 2001 05:59:59 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? No, you are right. FreeBSD's implementation is unnecessarily slow. > 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 would much prefer the "NFS credential" approach to doing this, for obvious reasons. > > > 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 instantiate a credential make the NFS RPC <hang for a long time> <kill the process> <destroy the credential holder entirely> free the credential > 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. It was not clear to me from a casual perusal of the code whether or not holding a reference to a credential used by a process would keep it from going away, or if it always went away on the 1->0 decrement. It seems to me that credential instantiation becomes a problem, and it also seems to me that this is what you are trying to fix with your changes elsewhere. Eventually, the credential has to come from somewhere, and to come from somewhere, it has to be allocated. > 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. Yep. 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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104062308.QAA05544>