From owner-freebsd-current Fri Feb 8 13: 0:25 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 F28DD37B421 for ; Fri, 8 Feb 2002 13:00:17 -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 <20020208210017.JZKU1672.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 8 Feb 2002 21:00:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA03315; Fri, 8 Feb 2002 12:50:35 -0800 (PST) Date: Fri, 8 Feb 2002 12:50:34 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: ucred for threads In-Reply-To: <20020208195407.H9920-100000@gamplex.bde.org> 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 Fri, 8 Feb 2002, Bruce Evans wrote: [...] > > > > if (td->td_ucred != p->p_ucred) { > > PROC_LOCK(p); > > if (td->td_ucred) { > > crfree(td->td_ucred); > > td->td_ucred = NULL; > > } > > if (p->p_ucred != NULL) { > > td->td_ucred = crhold(p->p_ucred); > > } > > PROC_UNLOCK(p); > > } > > I deleted too much of the followup to this, so I can't quote it. > > Races here could be reduced by putting some sort of synchronization > instruction at the beginning. Then there would only be a race between > executing the sync instruction and checking p_ucred. The race window > could be very large if the process is preempted in between. But this > race is obviously unavoidable in the current framework. You may end > up with a slightly stale td_ucred, but this is insignificantly different > from ending up with a slightly stale td_ucred when p_ucred changes > just after you release the lock. Both can have almost any amount of > staleness if processes can be preempted... > > Without the sync instruction, the race starts a little earlier, in > userland. It's not so obvious that the effects of this race are not > really different from the the effects of p_ucred changing after you > release the lock, but I think they are. Terry argued this point from > a different viewpoint. That's my point. There is already an unavoidable (by us here) race on the macro level between two threads of the same process. The micro race introduced here is irrelevant in comparison, and if you solve the macro race, the micro one is solved for free, so it's pointless trying to protect against it here. John would like to clear the ucred while the thread is in user space just as a debug aid to help catch any bad uses (I guess during fast interrupts or something), but that reason asside there is no reason to do so, and a good reason to keep the ucreds. > > Bruce > > > 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