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