Re: PTRACE_DETACH without stop [Re: [PATCH 04/11] ptrace: implement PTRACE_INTERRUPT]

[Tejun Heo <tj@kernel.org>]

Hey,

On Sun, May 15, 2011 at 07:39:40PM +0200, Jan Kratochvil wrote:
> #include <unistd.h>
> #include <sys/wait.h>
> #include <sys/ptrace.h>
> #include <stdio.h>
> #include <stdlib.h>
> static int status;
> static pid_t child;
> void
> handler (int signo)
> {
>   puts ("PASS");
>   exit (0);
> }
> /* Ensure CHILD is stopped even if it is running now - for PTRACE_DETACH.  */
> void
> stop_child_for_detach (void)
> {
>   kill (child, SIGCONT);	/* To be PTRACE_INTERRUPT in the future.  */
>   /* The problem - here a signal may get lost.  */
>   wait (&status);
> }
> int
> main (void)
> {
>   child = fork ();
>   switch (child)
>     {
>     case 0:
>       signal (SIGUSR2, handler);
>       ptrace (PTRACE_TRACEME, 0, NULL, NULL);
>       raise (SIGUSR1);
>       puts ("FAIL");
>       exit (1);
>     default:
>       wait (&status);
>       /* Sent by arbitrary external program.  */
>       kill (child, SIGUSR2);
>       /* Comment out for PTRACE_DETACH not requiring stopped tracee.  */
> #if 1
>       ptrace (PTRACE_CONT, child, NULL, NULL);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You can lose signal here.  You must check which trap happened why and
then take action accordingly.  Argh... we really need better
documentation of ptrace behaviors and traps.  Anyways, sans the
confusion between debugger sent signals and signals from other sources
and the side effects caused by debugger sent ones, the current ptrace
interface isn't broken to the point where you just lose signal.

>       stop_child_for_detach ();
> #endif
>       ptrace (PTRACE_DETACH, child, NULL, NULL);
>     }
>   return 0;
> }
> 
> 
> > The reason why I'm reluctant to drop trapped requirement from both
> > SEIZE and DETACH is that removing those synchronization points opens
> > up a lot of corner cases.
> 
> They are either (currently) in the userland or they would be in the kernel.

Nope.  What userland is currently dealing with isn't that type of
conditions.  It's dealing with nasty side effects of implied and
required signals, which will be removed with the new interface.  Those
attach/detach sync points are currently in the kernel and wouldn't
change with the proposed updates.  You're suggesting to remove them.

So, it's not about moving them, at all.  It's about removing them.

That said, it might not be such a bad idea.  Let's see how difficult
or easy it actually is.

Thanks.

-- 
tejun