Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message

[Oleg Nesterov]

On 11/29, Dmitry V. Levin wrote:
>
> 2. Document these values

sure, they should be documented and live in include/uapi/,

> chosen to avoid collisions with ptrace_message values
> set by other ptrace events

this is what I can't understand. But to clarify, I don't really care and
won't argue.

If an application wants to use PTRACE_GETEVENTMSG to distinguish entry/exit
(without PTRACE_GET_SYSCALL_INFO) it needs to do wait(status) and check status
anyway, otherwise PTRACE_GETEVENTMSG is simply pointless (wrt syscall entry/
exit). So we do not care if PTRACE_EVENTMSG_SYSCALL_ENTRY conflicts with, say,
SECCOMP_RET_DATA.

> so that PTRACE_GETEVENTMSG users can easily tell
> whether this new semantics is supported by the kernel or not.

Yes. And how much this can help? Again, an application can trivially detect
if this feature implemented or not, and it should do this anyway if it wants
to (try to) use PTRACE_EVENTMSG_SYSCALL_ENTRY/EXIT ?


Again, I won't reallly argue. But if you insist that these values must be
unique then you probably need to add

	BUILD_BUG_ON(PTRACE_EVENTMSG_SYSCALL_ENTRY <= PID_MAX_LIMIT);

?

OK, please forget...

Oleg.