Re: Thread deficiencies
"Theodore Y. Ts'o" wrote:
>
> Date: Mon, 3 Jan 2000 21:47:28 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>
> 1. pthreads says that all threads share the uid/gid stuff.
>
> To support this requires a setuid() in one thread changes the
> security credentials of another thread on the fly _during_ a
> syscall. Right now we have no locking on uid/gid paths and those
> variables are very much critical performance points.
>
> That one isn't that hard. Setuid() calls aren't all that common, so
> simply making setuid() take the global kernel lock if the credentials
> structure (we would need to move the uid/gid/group information to a
> creds structure) is shared, probably isn't that unreasonable.
>
> (I.e., if a process does a clone(CLONE_CREDS), then set the a
> creds_cloned flag in the process, which is cleared if the process does a
> subsequent exec. The other process might have the creds_cloned flag set
> when it doesn't need it, but all that will do is cause an unneeded big
> kernel lock when it calls setuid, which is probably acceptable.)
>
> We have real people writing real applications and consistently
> finding pthreads as designed is unusable. Pthreads needs to work, but
> since its already a performance disaster it shouldnt be allowed to
> intrude on sensible applications using efficient interfaces. Just
> like with hardware - Linux has to make the fast stuff go very fast
> and not cripple the fast stuff for broken stuff.
>
> True, but if our pthreads implementation is far more inefficient than
> the pthreads implementation of other Unices, Linux isn't going to look
> all that good to application writers. We have to balance that against
> not screwing up the efficiency of the "better" interfaces, and keeping
> the kernel implementation relatively clean, but I think we can do better
> than what we have right now.
>
> I suspect part of the problem is that most of the kernel developers have
> a very different sense of the importance/priority of getting this
> address than most of the applications developers.
>
However, do the credential *users* even check the global kernel lock
(probably not?) The values are small enough -- even with 32-bit uids --
that they are atomic on all platforms, so that is not the problem, but
of course the problem is how do tasks deal with having this stuff
changed underneath them...
I think if it was only uid and gid, we probably could structure the
readout points so that they don't need locking by virtue of the small
datum size. However, the list of auxilliary groups is another matter
entirely. I need to look at how that is handled now, but I won't get a
chance to do that properly until I return to work (Jan 12, 2000.)
-hpa
Reply to: