Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> On Mon, Jun 21, 2021 at 11:59 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>>
>> There's a large mess around do_exit() - we have a bunch of
>> callers all over arch/*; if nothing else, I very much doubt that really
>> want to let tracer play with a thread in the middle of die_if_kernel()
>> or similar.
>
> Right you are.
>
> I'm really beginning to hate ptrace_{event,notify}() and those
> PTRACE_EVENT_xyz things.
>
> I don't even know what uses them, honestly. How very annoying.
Modern strace does. Modern gdb appears not to.
However strace at least does not read the exit code,
or really appear to care about stopping for PTRACE_EVENT_EXIT.
I completely agree with you that they are very annoying.
> I guess it's easy enough (famous last words) to move the
> ptrace_event() call out of do_exit() and into the actual
> exit/exit_group system calls, and the signal handling path. The paths
> that actually have proper pt_regs.
>
> Looks like sys_exit() and do_group_exit() would be the two places to
> do it (do_group_exit() would handle the signal case and
> sys_group_exit()).
For other ptrace_event calls I am playing with seeing if I can split
them in two. Like sending a signal. So that we can have perform all
of the work in get_signal.
I think we can even change exit_group(2) and exit(2) so that (at least
when ptraced) they just send the ``event signal'' and then the signal
handling path handles all of the ptrace stuff.
When I started it was just going to be exit and PTRACE_EVENT_EXIT and
some old architectures, and that a generic solution was going to be
hard.
I still think we are going to need to fix the io_uring threads on the
architectures that use the caller saved register optimization like alpha
and m68k. But I think we can handle the rest in generic code.
Eric
