Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Feb 2002 18:17:25 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        current@freebsd.org, bde@freebsd.org, Alfred Perlstein <bright@mu.org>
Subject:   Re: ucred holding patch, BDE version
Message-ID:  <Pine.BSF.4.21.0202111759140.18316-100000@InterJet.elischer.org>
In-Reply-To: <XFMail.020211204407.jhb@FreeBSD.org>

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
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 <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 


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: <http://docs.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202111759140.18316-100000>