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 for Android: free password hash cracker in your pocket
[<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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ