On Fri, Sep 12, 2025 at 1:55 PM Jiri Olsa <[email protected]> wrote: > > On Fri, Sep 12, 2025 at 01:28:55PM -0700, Ihor Solodrai wrote: > > On 9/9/25 9:41 AM, Andrii Nakryiko wrote: > > > On Tue, Sep 9, 2025 at 8:39 AM Jiri Olsa <[email protected]> wrote: > > > > > > > > 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 <[email protected]> > > > > > > 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? 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? > but the bpf selftests patches could be applied on bpf-next/master and disabled > in CI until tip/perf/core changes are merged in? > > thanks, > jirka > > > > Thanks! > > > > $ git log -1 --oneline > > a578b54a8ad2 (HEAD -> master, origin/master, origin/HEAD, > > kernel-patches/bpf-next) Merge branch > > 'bpf-report-arena-faults-to-bpf-streams' > > $ b4 am [email protected] > > [...] > > $ git am > > ./v3_20250909_jolsa_uprobe_bpf_allow_to_change_app_registers_from_uprobe_registers.mbx > > Applying: bpf: Allow uprobe program to change context registers > > Applying: uprobe: Do not emulate/sstep original instruction when ip is > > changed > > error: patch failed: kernel/events/uprobes.c:2768 > > error: kernel/events/uprobes.c: patch does not apply > > Patch failed at 0002 uprobe: Do not emulate/sstep original instruction when > > ip is changed > > [...] > > > > > > > > > include/linux/bpf.h | 1 + > > > > kernel/events/core.c | 4 +++ > > > > kernel/events/uprobes.c | 7 +++++ > > > > kernel/trace/bpf_trace.c | 7 +++-- > > > > tools/testing/selftests/bpf/prog_tests/attach_probe.c | 28 > > > > +++++++++++++++++ > > > > tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c | 27 > > > > ++++++++++++++++ > > > > tools/testing/selftests/bpf/prog_tests/uprobe.c | 156 > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > > > > tools/testing/selftests/bpf/progs/kprobe_write_ctx.c | 22 > > > > +++++++++++++ > > > > tools/testing/selftests/bpf/progs/test_uprobe.c | 38 > > > > +++++++++++++++++++++++ > > > > 9 files changed, 287 insertions(+), 3 deletions(-) > > > > create mode 100644 > > > > tools/testing/selftests/bpf/progs/kprobe_write_ctx.c > >
