Date: Fri, 8 Feb 2002 12:50:34 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG Subject: Re: ucred for threads Message-ID: <20020212021209.B8EF49F2FC@okeeffe.bestweb.net>
next in thread | raw e-mail | index | archive | help
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
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?20020212021209.B8EF49F2FC>