thread groups bug?
Hi Linus,
If the master thread of a thread group (PID==TGID) performs an execve() then it is possible to end up with two or more thread groups with the same TGID.
Would you be willing to have an execve() on the master thread kill all the other threads? (And thus be slightly closer to POSIX compliance).
Similarly, if the master thread exits, should all the other threads be killed too?
If a subsidary thread does an execve(), then what should happen? I can see two ways of handling it: (1) Make it seem that the master thread did an execve(), and kill all the other threads (which is closer to POSIX); and (2) allow the child thread to depart the thread group and set up by itself (as happens now).
Of course, comparing Linux thread groups to POSIX threads doesn't hold up very well:-)
David
Quoted 3 lines · David Howells
If the master thread of a thread group (PID==TGID) performs an
execve()then it is possible to end up with two or more thread groups with the same TGID.
No.
When they have the same TGID, they _are_ the same thread group.
There is absolutely _zero_ correlation between thread ID and MM. Never has been, never will be. An execve() is a total non-event from a TGID perspective.
If you expect POSIX behaviour, you do not do execve's from the master. It's that simple.
(Note that if you want POSIX behaviour, you're catching execve() anyway, so the matter is moot).
Linus
Quoted 2 lines
When they have the same TGID, they _are_ the same thread group.
Apparently not so... Doing an execve() on the master thread breaks this internally by removing the master thread from the thread-group ring without resetting the TGID on all subsidiary threads. So if one of the subsidiary threads thinks its TGID is x before an execve on the master, then if it tries to use that TGID after the execve on the master, it will affect the master's new thread group and not itself.
Quoted 3 lines
There is absolutely _zero_ correlation between thread ID and MM. Never has been, never will be. An
execve()is a total non-event from a TGID perspective.
Except that the execve() _can_ (a) change the TGID and (b) result in two effective thread groups of the same TGID as far as the kernel is concerned.
Quoted 2 lines
If you expect POSIX behaviour, you do not do execve's from the master. It's that simple.
My concern is not so much dealing with POSIX behaviour as coping with behaviour that can happen without getting snookered.
David
Quoted 3 lines · David Howells
Except that the
execve()_can_ (a) change the TGID and (b) result in two effective thread groups of the same TGID as far as the kernel is concerned.
You're right. I did that for security reasons - making sure that nobody can execve a suid application and then keep on sending signals to it under the auspices of thread groups. I'd forgotten about that thing.
Maybe killing the other threads on execve _is_ the right thing after all, if that also gives us POSIX behaviour.
Who actually maintains the pthread library? I don't think they use CLONE_THREAD at all yet, right?
Linus
--On Thursday, February 28, 2002 16:20:21 -0800 Linus Torvalds
Quoted 5 lines · <[email protected]> wrote:
Maybe killing the other threads on execve _is_ the right thing after all, if that also gives us POSIX behaviour.
Who actually maintains the pthread library? I don't think they use
CLONE_THREADat all yet, right?
As far as I know, Linuxthreads is maintained by Ullrich Drepper, and it doesn't use CLONE_THREAD. IBM's NGPT pthread library does use CLONE_THREAD, and I'm the one who's handling kernel issues related to it.
I could code up something that does a 'kill the thread group on execve' if you'd like me to.
Dave McCracken
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
[email protected] T/L 678-3059