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.
