On Mon, Mar 30, 2026 at 10:09 AM Alexei Starovoitov <[email protected]> wrote: > > On Mon, Mar 30, 2026 at 9:44 AM Song Liu <[email protected]> wrote: > > > > On Sun, Mar 29, 2026 at 10:38 PM Leon Hwang <[email protected]> wrote: > > > > > > On 28/3/26 05:39, Song Liu wrote: > > > > On Thu, Mar 26, 2026 at 7:17 AM Leon Hwang <[email protected]> wrote: > > > [...] > > > >> @@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct > > > >> bpf_prog *prog, > > > >> tr = prog->aux->dst_trampoline; > > > >> tgt_prog = prog->aux->dst_prog; > > > >> } > > > >> + if (prog->type == BPF_PROG_TYPE_EXT && > > > >> + prog->aux->kprobe_write_ctx != > > > >> tgt_prog->aux->kprobe_write_ctx) { > > > >> + err = -EINVAL; > > > >> + goto out_unlock; > > > >> + } > > > > > > > > This also blocks uprobe+freplace when prog and tgt_prog have different > > > > kprobe_write_ctx, right? Is this the expected behavior? > > > > > > > > > > Intuitively, yes, this also blocks uprobe+freplace. > > > > > > However, how can we distinguish uprobe/kprobe here? > > > > > > At attach time, uprobe/kprobe is recognized by the target perf event > > > flags instead of BPF prog's expected_attach_type. Thus, we cannot infer > > > the use of prog by prog itself. > > > > Maybe we should introduce an attach type BPF_TRACE_UPROBE in a > > backward compatible way: > > - expected_attach_type = 0, it could be either kprobe or uprobe. > > - expected_attach_type = BPF_TRACE_UPROBE, it must be an uprobe. > > > > With this flag, we can allow uprobe+freplace when the user space sets > > BPF_TRACE_UPROBE properly. WDYT? > > New uapi just to fix a narrow bug? Not a good tradeoff.
Agreed. Maybe we should just land this set as-is and accept uprobe+freplace won't work in certain cases. In this case: Acked-by: Song Liu <[email protected]> Thanks, Song
