On Mon, Sep 15, 2025 at 01:10:33PM -0700, Andrii Nakryiko wrote: > 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?
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
