Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes:
On Mon, Jan 10, 2022 at 06:54:57PM +0100, Geert Uytterhoeven wrote:
In fact Michael did so in "[PATCH v7 1/2] m68k/kernel - wire up
syscall_trace_enter/leave for m68k"[1], but that's still stuck...
[1] https://lore.kernel.org/r/1624924520-17567-2-git-send-email-schmitzmic@xxxxxxxxx/
Looks sane, but I'd split it in two - switch to calling syscall_trace_{enter,leave}
and then handling the return values...
The former would keep the current behaviour (modulo reporting enter vs. leave
via PTRACE_GETEVENTMSG), the latter would allow syscall number change by tracer
and/or handling of seccomp/audit/whatnot.
For exit+signal work the former would suffice, and IMO it would be a good idea
to put that one into a shared branch to be pulled both by seccomp and by signal
series. Would reduce the conflicts...
Objections?
I have the version that Geert ack'ed queued up for v5.17 in my
signal-for-v5.17 branch, along with a couple others prior fixes in this
series of changes where it was clear they were just obviously correct
bug fixes. No need to delay the removal of profiling bits for example.
I would love to see the m68k perform syscall_trace_{enter,leave} but
just getting as far as ptrace_report_syscall will be enough to avoid any
dependencies on my side.
Eric
