Re: [PATCH v4 0/7] ptrace: introduce PTRACE_SET_SYSCALL_INFO API

[Sven Schnelle <svens@linux.ibm.com>]

"Dmitry V. Levin" <ldv@strace.io> writes:

> On Mon, Feb 03, 2025 at 12:35:42PM +0200, Dmitry V. Levin wrote:
>> 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?
>
> OK, I'm going to apply the following s390 workaround to the test:
>
> diff --git a/tools/testing/selftests/ptrace/set_syscall_info.c b/tools/testing/selftests/ptrace/set_syscall_info.c
> index 0ec69401c008..4198248ef874 100644
> --- a/tools/testing/selftests/ptrace/set_syscall_info.c
> +++ b/tools/testing/selftests/ptrace/set_syscall_info.c
> @@ -71,6 +71,11 @@ check_psi_entry(struct __test_metadata *_metadata,
>  		const char *text)
>  {
>  	unsigned int i;
> +	int exp_nr = exp_entry->nr;
> +#if defined __s390__ || defined __s390x__
> +	/* s390 is the only architecture that has 16-bit syscall numbers */
> +	exp_nr &= 0xffff;
> +#endif
>  
>  	ASSERT_EQ(PTRACE_SYSCALL_INFO_ENTRY, info->op) {
>  		LOG_KILL_TRACEE("%s: entry stop mismatch", text);
> @@ -84,7 +89,7 @@ check_psi_entry(struct __test_metadata *_metadata,
>  	ASSERT_TRUE(info->stack_pointer) {
>  		LOG_KILL_TRACEE("%s: entry stop mismatch", text);
>  	}
> -	ASSERT_EQ(exp_entry->nr, info->entry.nr) {
> +	ASSERT_EQ(exp_nr, info->entry.nr) {
>  		LOG_KILL_TRACEE("%s: syscall nr mismatch", text);
>  	}
>  	for (i = 0; i < ARRAY_SIZE(exp_entry->args); ++i) {

Fine with me. As you already noted only 16 bit of the syscall number is
stored in pt_regs::int_code. A quick hack would be possible to do sign
extensions, so -1 would work. But i think this would be odd, because
positive numbers would still be limited.

So i think the patch you proposed is fine.