Re: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT andgroup stop notification, take#4

[Denys Vlasenko]

On Thu, Jun 2, 2011 at 2:31 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> Hello, Oleg.
>
> On Wed, Jun 01, 2011 at 02:39:03PM +0900, Tejun Heo wrote:
>> I'll test different corner cases (different thread doing
>> waking/sleeping, race against INTERRUPT kind of things) and let you
>> know how it goes.
>
> I've tested threaded one and INTERRUPT immediate re-triggering and at
> least the apparent cases work fine.  I've re-generated the git tree on
> top of 3.0-rc1 with the updated patches.
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-ptrace-seize
>
> The commit ID should be 7eae14288e745cfaabeb035fa67f89eb63a1aff7.  As
> git.korg seems to be taking quite a while to sync, it might be a
> better idea to pull from master.korg.
>
>  ssh://master.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-ptrace-seize
>
> IIRC, pending issues are...
>
> * Which signo to use in exit_code on STOP traps.

SIGSTOP/TSTP/TTIN/TTOU on entering group-stop,
SIGCONT on leaving group-stop.

> * Implicit signal on clone.

Best if it is converted to STOP trap (the same is one caused by INTERRUPT).

I guess this may be optionally changed
(similar to how PTRACE_O_TRACEEXEC
changes post-execve SIGTRAP into PTRACE_EVENT_EXEC).

Why not turn it on *unconditionally* on SEIZE?
Because otherwise ptrace users will turn into

if (we_used_SEIZE)
    do_something;
else
    do_something_else;

maze, which is maintenance nightmare.
It's possible users will opt to not use new functionality at all
instead of going that way.

If everything is monolithically tied into SEIZE, users won't be able
to opt to use only easy parts of new functionality (such as
PTRACE_INTERRUPT and PTRACE_LISTEN) if this *forces* them
to also use harder parts of new functionality, in this case
forces them to double and obfuscate their existing code
which handles SIGSTOP-on-child-auto-attach. They don't really
want to, since this SIGSTOP *in practice* isn't that problematic.


> * What to do about events which are reported by genuine SIGTRAP
>  generation?

I don't understand what you meant here. Example(s)?


> * Group leader exit issue.

Ohhh this is an ugly one. It turns out it is linked to the question
of "how execve works under ptrace", in a non-obvious way.
I will respond in the second thread, with an example of current
kernel's breakage.

-- 
vda
--
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/