Date: Mon, 11 Feb 2002 17:21:34 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Alfred Perlstein <bright@mu.org>, jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version Message-ID: <3C686E1E.84A42678@mindspring.com> References: <Pine.BSF.4.21.0202111610040.18316-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > This makes little sense to me. > > > > Maybe I'm missing something, but by virtue of ownership we don't > > have to worry about the ucred's refcount on entry into the kernel > > because it is the owner and no one else is allowed to change our > > privledges besideds ourselves via set[ug]id(). > > multiple threads can do it.. > > The proclock is needed to get the reference, > guarding against other threads, and giant is needed fo rnot to free it > because if it reaches a refcount of 0 it needs to call free(). (which john > assures me needs Giant at this time). > We could avoid the proclock with judicious use of an atomic refcount > incrementing method. > > When Giant goes away it won't be so bad but it will STILL be quicker to > not drop it across userland. The "multiple threads" argument is bogus, since the calls to [gs]et[ug]id() are on a per process, not a per thread basis. An argument which *may* not be bogus (I am unconvinced) is that creds are immutable once instanced, and that the calls to [gs]et[ug]id() instance a new cred and replace, rather than changing an existing cred (this logically follows from credential inheritance, or the first set call would change the cred used by "init" and all other processes). Personally, I still do not understand the need to have a cred reference per thread, the only thing that makes any sense about that is to optimize the degenerate case of a daemon that makes calls as another ID, on behalf of a lot of users (or, sequentially, at least, different users). One example of such a program would be SAMBA (but *not* NFS, due to "access" semantics on objects based on path component access exclusion by credential not being an effective mechanism for NFS file handles). I think that you would need to have [gs]et[ug]id() be on a per thread basis for this to be an efficiency, and I think trying to do this pessimizes everything else. My gut tells me that creds should be per process, and that the references to them should be taken sparingly, and then only if a need can be justified, rather than "just in case some day". Kirk at one time called vnodes "the structure that ate the kernel"; he was wrong: it was creds. Perhaps this dicsussion is enough impetus to justify revisiting the atomic_t type definitions, which would be useful as reference counted hold/release mechanisms that would obviate the need for locks here? This would at least let you defer getting rid of the per thread cred instances until later. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C686E1E.84A42678>