On Tue, Sep 2, 2025 at 7:38 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
>
> Adding support to attach unique uprobe through uprobe multi link
> interface.
>
> Adding new BPF_F_UPROBE_MULTI_UNIQUE flag that denotes the unique
> uprobe creation.
>
> Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx>
> ---
> include/uapi/linux/bpf.h | 3 ++-
> kernel/trace/bpf_trace.c | 4 +++-
> tools/include/uapi/linux/bpf.h | 3 ++-
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 233de8677382..3de9eb469fe2 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1300,7 +1300,8 @@ enum {
> * BPF_TRACE_UPROBE_MULTI attach type to create return probe.
> */
> enum {
> - BPF_F_UPROBE_MULTI_RETURN = (1U << 0)
> + BPF_F_UPROBE_MULTI_RETURN = (1U << 0),
> + BPF_F_UPROBE_MULTI_UNIQUE = (1U << 1),
I second Masami's point. "exclusive" name fits better.
And once you use that name the "multi_exclusive"
part will not make sense.
How can an exclusive user of the uprobe be "multi" at the same time?
Like attaching to multiple uprobes and modifying regsiters
in all of them? Is it practical ?
It feels to me BPF_F_UPROBE_EXCLUSIVE should be targeting
one specific uprobe.
