Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Feb 2002 18:17:25 -0800 (PST)
From:      Julian Elischer <>
To:        John Baldwin <>
Cc:,, Alfred Perlstein <>
Subject:   Re: ucred holding patch, BDE version
Message-ID:  <>
In-Reply-To: <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

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
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

> > 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 <>  <><
> "Power Users Use the Power to Serve!"  -
> To Unsubscribe: send mail to
> with "unsubscribe freebsd-current" in the body of the message

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

Want to link to this message? Use this URL: <>