From owner-freebsd-arch Mon Apr 9 15:44:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id AE09937B42C; Mon, 9 Apr 2001 15:44:52 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id PAA23838; Mon, 9 Apr 2001 15:44:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAsCaOFU; Mon Apr 9 15:44:46 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA02241; Mon, 9 Apr 2001 15:44:48 -0700 (MST) From: Terry Lambert Message-Id: <200104092244.PAA02241@usr08.primenet.com> Subject: Re: Eliminate crget() from nfs kernel code? To: jhb@FreeBSD.org (John Baldwin) Date: Mon, 9 Apr 2001 22:44:48 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.org, dillon@earth.backplane.com ((Matt Dillon)), rwatson@FreeBSD.org ((Robert Watson)) In-Reply-To: from "John Baldwin" at Apr 09, 2001 01:04:34 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> make the NFS RPC with an existing credential > > > > instantiate a credential > > make the NFS RPC > > > > > > > > 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. Looking at the code less casually, it seems to always go away on the 1->0 decrement. 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. > > 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. > > Erm, have you worked with refcount'd things before? :-P We malloc a new > copy in crdup() (which can be called by crcopy if needed) and we only free when > the refcount goes to zero. By bumping the refcount around the RPC, the cred > stays valid until the crfree() after the RPC returns, even if the process > terminates and goes away. Really, this isn't rocket science. I think we are talking past each other. See my oprhan credential comment, above. I also don't think getting rid of crget() is going to "save the world". 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. I think that for the NFS case, the best thing to do would be to create a persistant "root" credential, and pass that, instead. 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). 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