On 08-Feb-02 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.
> 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);
>         }
> THis is actually not dependent on KSE (though I originally needed it 
> for KSE I have since decided that it would be a good idea anyhow).
> Do those who deal in ucreds (probably jhb and Robert W) 
> agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
> patches a bit more :-)

This code is not safe on SMP non-i386 machines (i.e. ia64, sparc64, alpha, and
possibly p3 and later i386's) because the p_ucred value you read could easily
be a stale value, thus rendering the test invalid.  You need the lock for the
compare.  Conceptually minimizing the crfree's isn't bad I guess.  However, the
td_ucred pointer should nto be read if the thread is not in the kernel, and
having it set to NULL when we leave the kernel provides a conveninet way of
ensuring this doesn't happen since we will panic if we do.


John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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