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