Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang afterPTRACE_ATTACH
From: Tejun Heo
Date: Mon Feb 28 2011 - 08:29:51 EST
On Mon, Feb 28, 2011 at 02:16:48PM +0100, Denys Vlasenko wrote:
> (gdb) print getpid()
> gdb modifies IP, sets breakpoint on return address, and issues PTRACE_CONT(0).
> Kernel has to put the tracee into group-stop, right?
> Becuase if it doesn't, if it makes tracee run, then the kernel is
> still broken. For example,
> stracing a program and sending SIGSTOP on it won't work: the sequence
> of events will be
> got SIGSTOP because SIGSTOP was delivered
> PTRACE_SYSCALL(SIGSTOP) - "inject it"
> got SIGSTOP because tracee is in group-stop now
> PTRACE_SYSCALL(SIGSTOP) - equivalent to PTRACE_SYSCALL(0)
> because we aren't in signal delivery ptrace-stop
> and tracee continues.
> That's why I think gdb's "print getpid()" today depends on the bug.
> If we simply fix the bug (by making PTRACE_CONT/SYSCALL(0)
> re-enter group-stop), then "print getpid()" will stop working
> for stopped tracees.
There's no reason to make the tracee re-enter group stop after pulling
it out to execute 'print getpid()'. The only thing necessary is a way
for the debugger to find out that group stop has been lifted. The
debugger then can resume the tracee if it wishes so. ie. group stop
becomes a trap point + a state which the debugger can monitor. If the
debugger wants the tracee to follow the jctl behavior, it can do so by
resuming the tracee as it sees fit.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/