On Mon, Feb 03, 2025 at 10:29:37AM +0100, Alexander Gordeev wrote: > On Mon, Feb 03, 2025 at 08:58:49AM +0200, Dmitry V. Levin wrote: > > Hi Dmitry, > > > PTRACE_SET_SYSCALL_INFO is a generic ptrace API that complements > > PTRACE_GET_SYSCALL_INFO by letting the ptracer modify details of > > system calls the tracee is blocked in. > ... > > FWIW, I am getting these on s390: > > # ./tools/testing/selftests/ptrace/set_syscall_info > TAP version 13 > 1..1 > # Starting 1 tests from 1 test cases. > # RUN global.set_syscall_info ... > # set_syscall_info.c:87:set_syscall_info:Expected exp_entry->nr (-1) == info->entry.nr (65535) > # set_syscall_info.c:88:set_syscall_info:wait #3: PTRACE_GET_SYSCALL_INFO #2: syscall nr mismatch > # set_syscall_info: Test terminated by assertion > # FAIL global.set_syscall_info > not ok 1 global.set_syscall_info > # FAILED: 0 / 1 tests passed. > # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0 > > I remember one of the earlier versions (v1 or v2) was working for me. > > Thanks! In v3, this test was extended to check whether PTRACE_GET_SYSCALL_INFO called immediately after PTRACE_SET_SYSCALL_INFO returns the same syscall number, and on s390 it apparently doesn't, thanks to its implementation of syscall_get_nr() that returns 0xffff in this case. To workaround this, we could either change syscall_get_nr() to return -1 in this case, or add an #ifdef __s390x__ exception to the test. What would you prefer? -- ldv
