Re: [tip: perf/core] libbpf: Detect uprobe syscall with new error

From: Ingo Molnar

Date: Sat Jul 04 2026 - 04:58:03 EST



* tip-bot2 for Jiri Olsa <tip-bot2@xxxxxxxxxxxxx> wrote:

> The following commit has been merged into the perf/core branch of tip:
>
> Commit-ID: c450c804b641003e0328e4b2ebf55c05f67e3d08
> Gitweb: https://git.kernel.org/tip/c450c804b641003e0328e4b2ebf55c05f67e3d08
> Author: Jiri Olsa <jolsa@xxxxxxxxxx>
> AuthorDate: Fri, 03 Jul 2026 13:49:11 +02:00
> Committer: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> CommitterDate: Fri, 03 Jul 2026 16:30:36 +02:00
>
> libbpf: Detect uprobe syscall with new error
>
> In the previous optimized uprobe fix we changed the syscall
> error used for its detection from ENXIO to EPROTO.
>
> Changing related probe_uprobe_syscall detection check.
>
> Fixes: 05738da0efa1 ("libbpf: Add uprobe syscall feature detection")
> Fixes: af734a7ddb4e ("uprobes/x86: Move optimized uprobe from nop5 to nop10")
> Fixes: 40b54d7e3dab ("uprobes/x86: Move optimized uprobe from nop5 to nop10")
> Fixes: 5c3c59c7952a ("uprobes/x86: Move optimized uprobe from nop5 to nop10")

The last 3 Fixes tags are bogus (just like the triplication itself),
those SHA1's don't exist anymore due to rebases.

I suppose it's meant to be:

Fixes: 554ba38456da ("uprobes/x86: Move optimized uprobe from nop5 to nop10")

But why are we applying and then fixing later on a regression in
an earlier commit in the same series to begin with??

Anyway, I've fixed up the tag mishaps in a rebase in tip:perf/core,
but can we please not do something like this in the future?

Thanks,

Ingo