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
