Date: Mon, 09 Apr 2001 15:59:49 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert@primenet.com> Cc: ((Robert Watson)) <rwatson@FreeBSD.org>, ((Matt Dillon)) <dillon@earth.backplane.com>, freebsd-arch@FreeBSD.org Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <XFMail.010409155949.jhb@FreeBSD.org> In-Reply-To: <200104092244.PAA02241@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09-Apr-01 Terry Lambert wrote: >> >> 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. >> >> Geez, that must've been _real_ casual, Terry. :) > > Maybe I was too opaque in my statement? > > By "reference", I did not mean an increment of cr_ref. Well, I'm not sure how else one holds a reference, but ok. > Looking at the code less casually, it seems to always go away on the > 1->0 decrement. Yes. > I can imagine cases where the NFS reference becomes the only > remaining reference for the credential. > > I think that that is a Bad Thing, since NFS outages can live > drastically longer than the referencing process that gave it > the credential. > > I can imagine a bunch of orphan credentials piling up in the > NFS code, waiting for the RPC to come back from a dead server. Ok, however, with the current crget() code, we would have even more of these lying around. At least by using p->p_ucred, processes that share the same ucred will use the same ucred's in NFS. The proposed change will result in _fewer_ credentials piling up in this case than just creating a new ucred for each call. > My complaint was that there is not a 1:1 correspondance between > credentials and sessions (or all my processes would point to the > same credential, and I would not need to have seperate per process > authentications to get the extra credential data for things like > SMB client FSs, etc.). The changed behaviour means I can't easily > have that in the future. It makes session management a pain in > the neck, and just that much harder to implement. Actually, assuming none of your processes are setuid, they will all point to the same credential. In fork() we simply bump the refcount on the ucred, we don't actually duplicate it into another ucred. > I think that for the NFS case, the best thing to do would be to > create a persistant "root" credential, and pass that, instead. So long as this doesn't give out extra privilege. > Doing anything else is likely to break somewhere, even if FreeBSD > never implements client cacheing (NFSv3 permits it over the lifetime > of a lease; NFSv4 practically demands it to get the best performance). I fail to see why using the actual credential from the requesting process instead of blindly granting root privileges will break client caching. If anything, I'm inclined to view it the other way around, but that's just me. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010409155949.jhb>