Hi Dmitry, On 2/27/23 16:33, Dmitry V. Levin wrote: > Hi, > > On Mon, Feb 27, 2023 at 02:28:45PM +0100, Alejandro Colomar wrote: > [...] >> Ahh, sorry, I forgot about that. I reworded it to the following: >> >> ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO >> >> Document the role of PTRACE_O_TRACESYSGOOD option in connection with >> PTRACE_GET_SYSCALL_INFO. >> >> Came upon this after writing a test program using PTRACE_O_TRACESYSGOOD. > > Just otherwise, PTRACE_O_TRACESYSGOOD was not used in that test, > otherwise there wouldn't be any question in the first place. > Did you mean PTRACE_GET_SYSCALL_INFO? > >> After failing to find what's wrong I posted a StackOverflow question >> which you can find right here: >> <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none> >> >> Nate Eldredge found out what happens by looking into the kernel's source >> code, here is a link to the relevant part >> <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018> >> >> In the code it can be seen that the union is filled if and only if the >> signal matches "SIGTRAP | 0x80", a signal which is only sent if the >> PTRACE_O_TRACESYSGOOD option is set. You can read about that in the >> PTRACE_O_TRACESYSGOOD section of ptrace(2)'s manual. > > Once again, this "if and only if" is confusing, as PTRACE_EVENT_SECCOMP > event that can happen when PTRACE_O_TRACESECCOMP option is enabled > fills the union with the data of type PTRACE_SYSCALL_INFO_SECCOMP. > > PTRACE_EVENT_SECCOMP stop is similar to system call enter stop, but it's > not exactly the same kind of stop. > > The note we're adding to the manual page is more correct in this regards. Okay, I'll let Fotios write the commit message, and will take it whatever it is :) Cheers, Alex > > -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature