Date: Thu, 07 Feb 2002 23:03:27 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: current@freebsd.org Subject: RE: ucred for threads Message-ID: <XFMail.020207230327.jhb@FreeBSD.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 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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.020207230327.jhb>