Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Feb 2002 20:20:40 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Julian Elischer <julian@elischer.org>
Cc:        <current@FreeBSD.ORG>
Subject:   Re: ucred for threads
Message-ID:  <20020208195407.H9920-100000@gamplex.bde.org>
In-Reply-To: <Pine.BSF.4.21.0202071633430.91961-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Feb 2002, Julian Elischer wrote:

> As part of the KSe stuff I ended up changing ht ebehaviour of threads with
> respect to their ucreds. Previously, they freed their ucred reference when
> they entered user space and picked them up again when they re-entered the
> kernel. It there was an AST then they re-loaded teh already freed ucred to
> perform the AST. (and then freed it again, (For each AST).
> Since each 'get' and free required a lock and unlock of the proc
> structure, this meant that there were at least 2 locks and 2 unlocks, and
> possibly many more, for the average kernel entry/exit pair.

The 2 locks and 2 unlocks pessimized syscall overhead by 10-20%.

> Since the chance that the ucred on the next entry is not the same as the
> thread already had on it's last kernel exit, is almiost negligible,
> it makes sence to hold the ucred acress the user period an dsimply check
> it agains the process's ucred on th enext entry.
>
> In the KSE code I have:
>  in trap(), and syscall()
>
>         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.

Bruce


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?20020208195407.H9920-100000>