Re: [PATCHv2 05/11] libbpf: Detect uprobe syscall with new error

[Jiri Olsa <olsajiri@gmail.com>]

On Mon, May 18, 2026 at 11:31:26AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Missing kernel dependency causes immediate selftest failure and libbpf feature detection breakage.
> - [High] libbpf feature detection breaks backward compatibility by not accepting the old ENXIO error code.
> --
> 
> commit 674b83913f8f61b2f16ba8f8b86e6bf8e84da5a3
> Author: Jiri Olsa <jolsa@kernel.org>
> 
> libbpf: Detect uprobe syscall with new error
> 
> This commit updates libbpf's feature detection and the uprobe selftests to
> expect the uprobe syscall to return -EPROTO instead of -ENXIO. This is in
> response to an optimized uprobe fix that changed the syscall's error code.
> 
> > diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> > index 4f19a0d79b0cf..a37aaea5253e5 100644
> > --- a/tools/lib/bpf/features.c
> > +++ b/tools/lib/bpf/features.c
> > @@ -577,10 +577,10 @@ static int probe_ldimm64_full_range_off(int token_fd)
> >  static int probe_uprobe_syscall(int token_fd)
> >  {
> >  	/*
> > -	 * If kernel supports uprobe() syscall, it will return -ENXIO when called
> > +	 * If kernel supports uprobe() syscall, it will return -EPROTO when called
> >  	 * from the outside of a kernel-generated uprobe trampoline.
> >  	 */
> > -	return syscall(__NR_uprobe) < 0 && errno == ENXIO;
> > +	return syscall(__NR_uprobe) < 0 && errno == EPROTO;
> 
> Is it possible this change breaks libbpf's backward compatibility with older
> kernels? Since probe_uprobe_syscall() detects uprobe syscall support on
> various kernel versions, replacing the check rather than allowing either
> (e.g., errno == ENXIO || errno == EPROTO) might cause libbpf to silently
> fail to detect uprobe support on kernels that predate the EPROTO change.

that's the idea, we don't want the feature to be used for kernel that
return -ENXIO

> 
> Also, looking at arch/x86/kernel/uprobes.c, the kernel-side change does
> not appear to be present in the tree yet:
> 
> SYSCALL_DEFINE0(uprobe)
> {
> 	...
> 	/* Allow execution only from uprobe trampolines. */
> 	if (!in_uprobe_trampoline(regs->ip))
> 		return -ENXIO;

huh? it's changed already via previous commit:
  uprobes/x86: Move optimized uprobe from nop5 to nop10

jirka

> 
> Will replacing this check cause immediate regressions for both feature
> detection and the selftests until the kernel dependency is merged?
> 
> [ ... ]
> 
> > diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> > index 955a37751b52d..c944136252c6d 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> > @@ -762,7 +762,7 @@ static void test_uprobe_error(void)
> >  	long err = syscall(__NR_uprobe);
> >  
> >  	ASSERT_EQ(err, -1, "error");
> > -	ASSERT_EQ(errno, ENXIO, "errno");
> > +	ASSERT_EQ(errno, EPROTO, "errno");
> 
> Similarly, does this selftest change introduce an immediate regression if
> the running kernel still returns -ENXIO?
> 
> >  }
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518105957.123445-6-jolsa@kernel.org?part=1