Date: Thu, 7 Feb 2002 16:44:17 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: current@freebsd.org Subject: ucred for threads Message-ID: <20020212021256.D57959F14A@okeeffe.bestweb.net>
next in thread | raw e-mail | index | archive | help
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 :-)
Julian
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?20020212021256.D57959F14A>