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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to