On Mon, 26 Nov 2018 15:56:43 +0100 Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > On 11/25, Elvira Khabirova wrote: > > > > + * These values are stored in task->ptrace_message by tracehook_report_syscall_* > > + * to describe current syscall-stop. > > + * > > + * Values for these constants are chosen so that they do not appear > > + * in task->ptrace_message by other means. > > + */ > > +#define PTRACE_EVENTMSG_SYSCALL_ENTRY 0x80000000U > > +#define PTRACE_EVENTMSG_SYSCALL_EXIT 0x90000000U > > Stupid question, why not > > #define PTRACE_EVENT_SYSCALL_ENTRY 8 > #define PTRACE_EVENT_SYSCALL_EXIT 9 > > right after other PTRACE_EVENT_* constants? I thought about adding new events for syscall {entry,exit}. For tracers, using new events means setting new options and checking for new values after waitpid(). They will also have to switch from using PTRACE_SYSCALL to PTRACE_CONT. Right now (with this version of the patch) tracers can use PTRACE_GETEVENTMSG without doing any additional configuration. More importantly, adding these events would require much more complex modifications of kernel code than this patch does. The only benefit I see from adding these events instead of letting syscall-stops put a value in ptrace_message is an ability to subscribe to syscall entries, but not to exits, and vice-versa, and I don't think it is worth it.