[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzaRxpR5XLJmFopwq-asBUv0vJ2RZtcx2f=+XbfcCgBeFA@mail.gmail.com>
Date: Fri, 17 Oct 2025 15:04:52 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Amery Hung <ameryhung@...il.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, alexei.starovoitov@...il.com,
andrii@...nel.org, daniel@...earbox.net, tj@...nel.org, martin.lau@...nel.org,
kernel-team@...a.com
Subject: Re: [PATCH bpf-next v3 2/4] bpf: Support associating BPF program with struct_ops
On Fri, Oct 17, 2025 at 2:56 PM Amery Hung <ameryhung@...il.com> wrote:
>
> Add a new BPF command BPF_PROG_ASSOC_STRUCT_OPS to allow associating
> a BPF program with a struct_ops map. This command takes a file
> descriptor of a struct_ops map and a BPF program and set
> prog->aux->st_ops_assoc to the kdata of the struct_ops map.
>
> The command does not accept a struct_ops program or a non-struct_ops
> map. Programs of a struct_ops map is automatically associated with the
> map during map update. If a program is shared between two struct_ops
> maps, prog->aux->st_ops_assoc will be poisoned to indicate that the
> associated struct_ops is ambiguous. The pointer, once poisoned, cannot
> be reset since we have lost track of associated struct_ops. For other
> program types, the associated struct_ops map, once set, cannot be
> changed later. This restriction may be lifted in the future if there is
> a use case.
>
> A kernel helper bpf_prog_get_assoc_struct_ops() can be used to retrieve
> the associated struct_ops pointer. The pointer returned, if not NULL, is
> guaranteed to be valid and point to a fully updated struct_ops struct.
> This is done by increasing the refcount of the map for every associated
> non-struct_ops programs. For struct_ops program reused in multiple
> struct_ops map, the return will be NULL. struct_ops implementers should
> note that the struct_ops returned may or may not be attached. The
> struct_ops implementer will be responsible for tracking and checking the
> state of the associated struct_ops map if the use case requires an
> attached struct_ops.
>
> Signed-off-by: Amery Hung <ameryhung@...il.com>
> ---
> include/linux/bpf.h | 16 ++++++++
> include/uapi/linux/bpf.h | 17 +++++++++
> kernel/bpf/bpf_struct_ops.c | 70 ++++++++++++++++++++++++++++++++++
> kernel/bpf/core.c | 3 ++
> kernel/bpf/syscall.c | 46 ++++++++++++++++++++++
> tools/include/uapi/linux/bpf.h | 17 +++++++++
> 6 files changed, 169 insertions(+)
>
[...]
> @@ -1394,6 +1401,69 @@ int bpf_struct_ops_link_create(union bpf_attr *attr)
> return err;
> }
>
> +int bpf_prog_assoc_struct_ops(struct bpf_prog *prog, struct bpf_map *map)
> +{
> + guard(mutex)(&prog->aux->st_ops_assoc_mutex);
> +
> + if (prog->aux->st_ops_assoc && prog->aux->st_ops_assoc != map) {
> + if (prog->type == BPF_PROG_TYPE_STRUCT_OPS) {
> + WRITE_ONCE(prog->aux->st_ops_assoc, BPF_PTR_POISON);
> + return 0;
> + }
> +
> + return -EBUSY;
> + }
> +
> + if (prog->type != BPF_PROG_TYPE_STRUCT_OPS)
> + bpf_map_inc(map);
if st_ops_assoc was already set to map before, we will bump refcount
one more time here, but we'll bpf_map_put() only once in
bpf_prog_disassoc_struct_ops(), no?
> +
> + WRITE_ONCE(prog->aux->st_ops_assoc, map);
> + return 0;
> +}
> +
> +void bpf_prog_disassoc_struct_ops(struct bpf_prog *prog)
> +{
> + struct bpf_map *map;
> +
> + guard(mutex)(&prog->aux->st_ops_assoc_mutex);
> +
> + map = READ_ONCE(prog->aux->st_ops_assoc);
> + if (!map || map == BPF_PTR_POISON)
> + return;
> +
> + if (prog->type != BPF_PROG_TYPE_STRUCT_OPS)
> + bpf_map_put(map);
> +
> + WRITE_ONCE(prog->aux->st_ops_assoc, NULL);
> +}
> +
[...]
Powered by blists - more mailing lists