On Mon, 11 Feb 2002, John Baldwin wrote:

> 
> On 12-Feb-02 Julian Elischer wrote:
> >  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.
> 
> _No_!  The proc lock is protecting p_ucred, it can't go away!  What _can_ go
> away is the per-ucred mutex to protect the refcount if we ever revive the
> refcount API.

hmm ok Alfred, here's the way I see it..
You are never permitted to "CHANGE" a cred.
You ALWAYS allocate another and switch them.
When you switch them you decrement the refcount of the old one.
If someone else takes a reference on it at the same moment that you 
drop it, then the order is important down to the bus-cycle
as to whether it gets freed or not. We already know that dereferencing it
from the proc structure is not important, because a "stale" ucred pointer
is only preventable from the userland. 
All that is important  is that the pointer is a REAL pointer to a cred
and that it is not allowed to go to 0 references in its way to 1
reference.
An atomic reference count increment that checks
against 0 would be part of it but might not be enough.
I think we also need to have a lock on something because
it might get freed and used for something else that happens to place a "1"
in that location inbetween the time that p->p_ucred is read
and the refcount is decremented.

As an asside:
I think that in NT they may have refcounts in the same location in all
structures as I think they derived all their structures from a bas class
that has ref counts. In that case it WOULD have a "1" in that location if
it were re-used. (It's been a long time since I saw NT code so I may be
wrong)

> 
> > When Giant goes away it won't be so bad but it will STILL be quicker to
> > not drop it across userland.
> 
> Yes.  Actually, calling free() can still be rather expensive even when Giant is
> gone.
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to