Messages in this thread | | | Date | Sat, 16 Oct 1999 15:11:12 +0200 (IST) | From | Alon Ziv <> | Subject | Re: CLONE_PTRACE implementation incomplete |
| |
On 15 Oct 1999, Andi Kleen wrote:
> 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/
| |