> drepper@cygnus.com (Ulrich Drepper) writes:
>
> > Andi Kleen <ak@muc.de> writes:
> >
> > > The original CLONE_PTRACE design included CLONE_PPID, but that got
> > > somehow dropped from the patch that finally appeared in the kernel
> > > tree. Mixing the two together is not a good idea IMHO.
> >
> > Well, then the CLONE_PTRACE can be removed altogether this it is useles.
>
> It would be easy work to add CLONE_PPID/CLONE_PARENT. There was a more
> complex patch floating around on l-k too that added three bits for this
> case too, but it always looked like overkill for me.
>
Well, as someone who worked on the `more complex' patch, I tend to
disagree...
First, the other patch actually added two features: one was the actual
CLONE_PARENT support, the other was called CLONE_WAIT. CLONE_WAIT was
(is) intended to allow any process to do a `wait4' on its siblings.
The extra flag we used was `CLONE_PPIDOK' (or `CLONE_ALLOW_PARENT'). This
is supposed to be set by the original task when it clones a child, to
allow it to use CLONE_PARENT. Without this, CLONE_PARENT introduces a
security risk, as a process may suddenly foist new children upon its
parent; sure, we can probably solve this by auditing all of the sensitive
applications for possible problems--- but why add such a risk in the first
place?
The CLONE_WAIT flag, with CLONE_PARENT, can give a very real benefit to
multithreaded apps. With these flags added, we can make the pthreads
library much more lightweight, as each thread becomes autonomous (without
the need for a central `manager thread' to coordinate everything).
> Do you have any specific application in mind ? It was originally done for
> gdb threads debugging [Randy Chapman's Microsoft gdb patch did use
> a similar hack], but that got obsolete with the OSF gdb changes that
> used a different way.
IIRC, Linus has already claimed once that he doesn't very much like the
whole reparenting mess introduced for debugging. He said that instead of
fixing some other bugs in this code, ptrace should be fixed so the ppid of
a process isn't changed just because it's being debugged. (Actually, he
proposed that the connection between debugger and debuggee shouldn't be
made using the p_pptr field, but through another specific field; I believe
this is even quite easy to achieve, as it's very similar to the CLONE_WAIT
flag's implementation...)
So, if this is fixed, CLONE_PTRACE can truly become standalone (it will
just copy the new p_dbptr field)...
Any takers? (I can only start on this when I have my new comp, which will
take a few more weeks...)
-az
------------------------+----------------------------------------------------
. __ | Phone: +972 3 5340753 (home), +972 3 9685882 (work)
_| / | email: alonz@usa.net
/ | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900, Israel
------------------------+----------------------------------------------------
<<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/