Date: Mon, 11 Feb 2002 17:51:13 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alfred Perlstein <bright@mu.org>, jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version Message-ID: <Pine.BSF.4.21.0202111744150.18316-100000@InterJet.elischer.org> In-Reply-To: <3C686E1E.84A42678@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Feb 2002, Terry Lambert wrote: > 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. there is no such thing as a per process syscall. Two threads can always do the same syscall at the same time. there needs to be a proc-lock to stop it from becoming chaotic in there. In actual fact, since you cannot alter a cred but only replace that which the process points to it's not quite that bad, but you need to either lock it or have atomic reference-counting that can handle the possibility that the cred could have bee decremented to 0 by another thread just before you checked it. > > 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). the cred that is in force at the time that the syscall STARTS is used for the full syscall otherwise you could have one cred used for the first part of a syscall and a completely differnet one used for the secnd part of a syscall. > > 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". creads can only be changed per process but the threads only pick up the change on next syscall startup. > > > Kirk at one time called vnodes "the structure that ate the > kernel"; he was wrong: it was creds. I believe it was Mike Karels. > > > 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. I've made that point before and I believe that jhb has said he would like such primatives. > > -- 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?Pine.BSF.4.21.0202111744150.18316-100000>