[lkml]   [2018]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message
On Thu, Nov 29, 2018 at 03:47:43PM +0100, Oleg Nesterov wrote:
> 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,

Yes, once the application has verified that the kernel implements this
feature, there is no risk of collision.

> > 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

How an application can easily detect whether this feature is implemented?
By invoking PTRACE_GETEVENTMSG after the first syscall stop reported by
wait and checking whether the returned value is either

So the question is, how can this value be equal to one of these constants
when this feature is not implemented? Can a value saved to ptrace_message
earlier by one of ptrace events be equal to one of these constants?

Imagine an application attaches to already existing process, enables
ptrace_message set to 1. If this application then exits and a new invocation
of the same application attaches to the same process, it will very likely see
this 1 returned by PTRACE_GETEVENTMSG if the feature is not implemented
in the kernel.

To avoid that kind of collisions, kernel should use different ptrace_message
values for syscall stops.

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

Yes, it's a good idea. What is the proper place for this check?

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2018-11-29 22:11    [W:0.105 / U:6.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site