Messages in this thread | | | Date | Sun, 25 Nov 2018 05:10:59 +0300 | From | "Dmitry V. Levin" <> | Subject | Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message |
| |
On Sat, Nov 24, 2018 at 03:54:02PM -1000, Joey Pabalinas wrote: > On Sun, Nov 25, 2018 at 02:22:27AM +0100, Elvira Khabirova wrote: > > Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and > > PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message > > for the duration of syscall-stops. > > This way ptracers can distinguish syscall-enter-stops > > from syscall-exit-stops using PTRACE_GETEVENTMSG request. > > Is there an advantage to using two constants instead of a single > sys_exit bit (set/unset for syscall-exit-stop/syscall-enter-stop)?
Given that without this patch the value returned by PTRACE_GETEVENTMSG during syscall stop is undefined, we need two different ptrace_message values that cannot be set by other ptrace events to enable reliable identification of syscall-enter-stop and syscall-exit-stop in userspace: if we make PTRACE_GETEVENTMSG return 0 or any other value routinely set by other ptrace events, it would be hard for userspace to find out whether the kernel implements new semantics or not.
-- ldv [unhandled content-type:application/pgp-signature] | |