Re: [PATCHv3 perf/core 0/6] uprobe,bpf: Allow to change app registers from uprobe registers

On Mon, Sep 15, 2025 at 01:10:33PM -0700, Andrii Nakryiko wrote:

On Fri, Sep 12, 2025 at 1:55 PM Jiri Olsa [off-list ref] wrote:

quoted

On Fri, Sep 12, 2025 at 01:28:55PM -0700, Ihor Solodrai wrote:

quoted

On 9/9/25 9:41 AM, Andrii Nakryiko wrote:

quoted

On Tue, Sep 9, 2025 at 8:39 AM Jiri Olsa [off-list ref] wrote:

quoted

hi,
we recently had several requests for tetragon to be able to change
user application function return value or divert its execution through
instruction pointer change.

This patchset adds support for uprobe program to change app's registers
including instruction pointer.

v3 changes:
- deny attach of kprobe,multi with kprobe_write_ctx set [Alexei]
- added more tests for denied kprobe attachment

thanks,
jirka


---
Jiri Olsa (6):
       bpf: Allow uprobe program to change context registers
       uprobe: Do not emulate/sstep original instruction when ip is changed
       selftests/bpf: Add uprobe context registers changes test
       selftests/bpf: Add uprobe context ip register change test
       selftests/bpf: Add kprobe write ctx attach test
       selftests/bpf: Add kprobe multi write ctx attach test

For the series:

Acked-by: Andrii Nakryiko <andrii@kernel.org>

Question is which tree will this go through? Most changes are in BPF,
so probably bpf-next, right?

Hi Jiri.

This series does not apply to current bpf-next, see below.

Could you please respin it with bpf-next tag?
E.g. "[PATCH v4 bpf-next 0/6] ..."

hi,
the uprobe change it needs to be on top of the optimized uprobes (tip/perf/core)

Is this what you happened to base it on (and thus diff context has
that arch_uprobe_optimize), or those changes are needed for correct
functioning?

yes

It seems like some conflict is inevitable, but on uprobe side it's two
lines of code that would need to be put after arch_uprobe_optimize
(instead of handler_chain), while on BPF side it's a bit more
invasive.

So unless tip/perf/core changes are mandatory for correct functioning,
I'd say let's rebase on top of bpf-next and handle that trivial merge
conflict during merge window?

ok, sounds good, will rebase/resend

thanks,
jirka