Re: [PATCH 1/5] ptrace: add PTRACE_SYSCALL_INFO_SECCOMP_SKIP

[Oleg Nesterov <oleg@redhat.com>]

On 07/02, Dmitry V. Levin wrote:
>
> On Thu, Jul 02, 2026 at 11:58:14AM +0200, Oleg Nesterov wrote:
> [...]
> > @@ -1047,6 +1069,11 @@ ptrace_set_syscall_info_entry(struct task_struct *child, struct pt_regs *regs,
> >  	if (nr != info->entry.nr)
> >  		return -ERANGE;
> >
> > +	syscall_set_nr(child, regs, nr);
> > +	if (nr == -1)
> > +		return __set_syscall_info_exit(child, regs,
> > +						info->entry.rval, info->entry.is_error);
>
> The kernel shouldn't suddenly start interpreting info->entry.rval and
> info->entry.is_error because the current users of this interface are not
> aware that the kernel might be doing it.  If we want to extend
> PTRACE_SYSCALL_INFO_ENTRY/PTRACE_SYSCALL_INFO_SECCOMP this way, we would
> have to require setting a flag in info->flags signalling the kernel that
> the user requests this new behaviour.

Ah. I forgot to mention that (obviously) this is a user-visible change,
and a new flag in info->flags will be safer. Of course.

Or we can define a special SKIP_AND_SET_RVAL value for info->entry.nr.

But I am just curious, will this change (without new flag) actually break
strace? What does strace do when it uses PTRACE_SYSCALL_INFO_ENTRY with
info->entry.nr == -1?

Oleg.