linux-kernel - Re: [GIT PULL] BPF changes for 6.18

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=whR4OLqN_h1Er14wwS=FcETU9wgXVpgvdzh09KZwMEsBA@mail.gmail.com>
Date: Tue, 30 Sep 2025 19:09:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>, Jiri Olsa <jolsa@...nel.org>
Cc: bpf@...r.kernel.org, daniel@...earbox.net, andrii@...nel.org, 
	martin.lau@...nel.org, peterz@...radead.org, kuba@...nel.org, 
	linux-kernel@...r.kernel.org, mingo@...nel.org, netdev@...r.kernel.org
Subject: Re: [GIT PULL] BPF changes for 6.18

[ Jiri added to participants ]

On Sun, 28 Sept 2025 at 08:46, Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> Note, there is a trivial conflict between tip and bpf-next trees:
> in kernel/events/uprobes.c between commit:
>   4363264111e12 ("uprobe: Do not emulate/sstep original instruction when ip is changed")
> from the bpf-next tree and commit:
>   ba2bfc97b4629 ("uprobes/x86: Add support to optimize uprobes")
> from the tip tree:
> https://lore.kernel.org/all/aNVMR5rjA2geHNLn@sirena.org.uk/
> since Jiri's two separate uprobe/bpf related patch series landed
> in different trees. One was mostly uprobe. Another was mostly bpf.

So the conflict isn't complicated and I did it the way linux-next did
it, but honestly, the placement of that arch_uprobe_optimize() thing
isn't obvious.

My first reaction was to put it before the instruction_pointer()
check, because it seems like whatever rewriting the arch wants to do
might as well be done regardless.

It's very confusing how it's sometimes skipped, and sometimes not
skipped. For example. if the uprobe is skipped because of
single-stepping disabling it, the arch optimization still *will* be
done, because the "skip_sstep()" test is done after - but other
skipping tests are done before.

Jiri, it would be good to just add a note about when that optimization
is done and when not done. Because as-is, it's very confusing.

The answer may well be "it doesn't matter, semantics are the same" (I
suspect that _is_ the answer), but even so that current ordering is
just confusing when it sometimes goes through that
arch_uprobe_optimize() and sometimes skips it.

Side note: the conflict in the selftests was worse, and the magic to
build it is not obvious. It errors out randomly with various kernel
configs with useless error messages, and I eventually just gave up
entirely with a

   attempt to use poisoned ‘gettid’

error.

             Linus