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
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message