[PATCH 1/5] ptrace: add PTRACE_SYSCALL_INFO_SECCOMP_SKIP

[Oleg Nesterov]

Or we can simply allow the ENTRY/SECCOMP -> EXIT transition, I dunno.
This is more safe.

But somehow I don't like the new PTRACE_SYSCALL_INFO_SECCOMP_SKIP...

Oleg.

On 07/02, Oleg Nesterov wrote:
>
> 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.