From owner-freebsd-current Mon Feb 11 19:49:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id BCE7E37B6C7; Mon, 11 Feb 2002 18:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020212022008.FOZU1672.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 12 Feb 2002 02:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA19275; Mon, 11 Feb 2002 18:17:27 -0800 (PST) Date: Mon, 11 Feb 2002 18:17:25 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: current@freebsd.org, bde@freebsd.org, Alfred Perlstein Subject: Re: ucred holding patch, BDE version In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 <>< 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