Re: [patch 13/18] entry: Make trace_syscall_enter() return type bool

On Thu, 09 Jul 2026 01:14:24 +0200
Thomas Gleixner <[email protected]> wrote:

> On Wed, Jul 08 2026 at 22:34, Thomas Gleixner wrote:
> > On Wed, Jul 08 2026 at 17:52, Michal Suchánek wrote:
> > Q: Is it perfect?
> > A: No
> >
> > Q: Can it be made perfect?
> > A: No, because you can't change history and established practice.
> >
> > Just for illustration. Changing the logic in trace_syscall_enter() to:
> >
> > --- a/kernel/entry/syscall-common.c
> > +++ b/kernel/entry/syscall-common.c
> > @@ -9,13 +9,15 @@
> >  
> >  bool trace_syscall_enter(struct pt_regs *regs, long *syscall)
> >  {
> > +	long orig_syscall = *syscall;
> > +
> >  	trace_sys_enter(regs, *syscall);
> >  	/*
> >  	 * Probes or BPF hooks in the tracepoint may have changed the
> >  	 * system call number. Reread it.
> >  	 */
> >  	*syscall = syscall_get_nr(current, regs);
> > -	return *syscall != -1L;
> > +	return *syscall == orig_syscall || *syscall != -1L;
> >  }
> >  
> >  void trace_syscall_exit(struct pt_regs *regs, long ret)
> >
> > does not make #2 magically go away. It's still the same problem whether
> > you like it or not.  
> 
> And just to be entirely clear, the syscall() interface has to be correct
> in the first place, but then it's all about performance.
> 
> So the sequence of:
> 
>    pt_regs = PUSH_REGS();
>    syscall = pt_regs->syscall_reg;
>    pt_regs->result = -ENOSYS;
> 
>    arch_syscall(pt_regs, syscall) {
>       if (likely(syscall_enter_from_user_mode(pt_regs, &syscall) {

I guess most architectures inline that to avoid the &syscall.
Otherwise you'd want:
	syscall = syscall_enter_from_user_mode(pt_regs, syscall);
with the 'error' return being selected to fail the test below
(which -1L converted to ~0UL will do nicely).

	David

>          if (syscall < SYSCALL_max)
>             pt_regs->result = invoke_syscall(pt_regs, syscall);
>       }
>       ,,,,
>    }
>    pt_regs->($RETURN_VALUE) = pt_regs->result;
>    POP_REGS();
>    return;
> 
> is the correct and obviuosly most efficient way idependent of the -1L
> return value overload in the original implementation, which this series
> gets rid of for clarity.
> 
> If an architecture decide[sd] to do otherwise and makes up it's own rules
> which only cover parts of the problem then it _is_ an architecture
> problem and not something which has to be solved by claiming that every
> architecture has to implement the same nonsense as you falsely claimed
> in your RFC^WPOC^Whack thread:
> 
>   "However, the API should be specified in a way that does not require
>    everyone implementing such flag."
> 
> There is _ZERO_ requirement for any architecture to implement that
> flag. Just because S390 decided it's a brilliant idea to do so does not
> make it a requirement for everyone.
> 
> No. Every other architecture got it right because they looked at the
> historical patterns despite having correct documentation at hand.
> 
> Feel free to prove me wrong with actual facts.
> 
> Thanks,
> 
>         tglx
>