Re: [PATCHv4 00/13] uprobes/x86: Fix red zone issue for optimized uprobes

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Jun 25, 2026 at 10:44:18PM -0700, Andrii Nakryiko wrote:
> On Mon, Jun 8, 2026 at 1:48 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Wed, Jun 3, 2026 at 11:59 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > >
> > > On Tue, May 26, 2026 at 10:58:27PM +0200, Jiri Olsa wrote:
> > > > hi,
> > > > Andrii reported an issue with optimized uprobes [1] that can clobber
> > > > redzone area with call instruction storing return address on stack
> > > > where user code may keep temporary data without adjusting rsp.
> > > >
> > > > Fixing this by moving the optimized uprobes on top of 10-bytes nop
> > > > instruction, so we can squeeze another instruction to escape the
> > > > redzone area before doing the call.
> > > >
> > > > Note we need upstream update first for patch 3 (github.com/libbpf/usdt),
> > > > if we decide to take this change.
> > > >
> > > > thanks,
> > > > jirka
> > > >
> > > >
> > > > v1: https://lore.kernel.org/bpf/20260514135342.22130-1-jolsa@kernel.org/
> > > > v2: https://lore.kernel.org/bpf/20260518105957.123445-1-jolsa@kernel.org/
> > > > v3: https://lore.kernel.org/bpf/20260521124411.31133-1-jolsa@kernel.org/
> > > >
> > > > v4 changes:
> > > > - do not use 2nd int3 (ont +5 offset) because the call instruction
> > > >   is allways the same for the given nop10 address [Andrii/Peter]
> > > > - unmap unused trampoline vma after unsuccesfull optimization [sashiko]
> > > > - small change to patch#2 moved user_64bit_mode earlier in the path
> > > >   and pass/use mm_struct pointer directly from arch_uprobe_optimize
> > > >   instead of gettting current->mm
> > > >   Andrii, keeping your ack, please shout otherwise
> > >
> > > hi,
> > > I think bots did not find anything substantial, I have just small
> > > selftests changes queued for v5
> > >
> > > any other feedback/review would be great
> > >
> >
> > one small nit on only, otherwise LGTM.
> >
> > Peter, Masami, Ingo, should this go through tip tree or should we
> > route this through bpf-next tree? I think we are fine either way, but
> > might be more convenient to route through bpf-next given libbpf and
> > BPF selftest changes.
> >
> 
> I'll assume that no one has any objections to route this through
> bpf-next. We got reviews from Oleg, so that's great. Jiri, seems like
> you will do small adjustments and send v5, please do, and then unless
> meanwhile no one raises any issues, this will go through bpf-next.
> Thanks!

Is it already applied? If not, I can stick it in tip/perf/core (and the
first in /urgent).