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? Thanks, Song
