Re: CLONE_PTRACE

["Andi Kleen" <ak _at_ suse.de>]

On Sat, Aug 19, 2000 at 11:05:27PM +0200, Mark Kettenis wrote:
>    Date: Sat, 19 Aug 2000 20:57:29 +0200
>    From: "Andi Kleen" <ak _at_ suse.de>
> 
>    > The filter is probably pretty essential to get adequate performance.
>    > I still think that my proposed change is cleaner.
> 
>    Yours just depends on all programs setting CLONE_PTRACE, which is a
>    bit if (to make it really useful for the debugger would require a
>    CLONE_NO_PTRACE and a sysctl, which would be too ugly)

The sentence came out wrong: 

	Yours just depends on all programs setting CLONE_PTRACE, which
	is a bit much to require for debugging.

> 
> Sorry I fail to understand what you're trying to say here.  Yes indeed
> the programmer must set CLONE_PTRACE to make the debugger aware of new
> threads.  That's an additional burden on the programmer, but not a
> very big one.  Most programmers will use a thread library, which will
> have the CLONE_PTRACE flag compiled in.  That's all-right since
> CLONE_PTRACE doesn't affect the program if it wasn't traced in the
> first place.

I think it is broken by design to require the programs to be debugger
aware. Also your fundamental assumption that everybody uses thread libraries
is wrong too. There are already lots of programs that use clone() directly.

> I fail to see why you'd need a CLONE_NO_PTRACE flag (that's the
> default) and what exactly you want to sysctl to set.

I was just thinking about the implications of your "inherit ptrace on fork"
approach. Unless you require the programs to be debugging aware the ptrace
cloning would need to be default. Some programs may not want it, so they
would need CLONE_NO_PTRACE.

Actually a sysctl would be wrong on second thought, a special flag for 
ptrace() that enables ptrace inheritance would make more sense.

But that's all mood I think, because PTRACE_SYSCALL + event filter + vmid
is a much more general solution that would cover many more cases.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/