From: Martin KaFai Lau <martin.lau@linux.dev>
To: Amery Hung <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
alexei.starovoitov@gmail.com, andrii@kernel.org,
daniel@iogearbox.net, tj@kernel.org, martin.lau@kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH bpf-next v7 2/6] bpf: Support associating BPF program with struct_ops
Date: Mon, 1 Dec 2025 21:40:19 -0800 [thread overview]
Message-ID: <569b74e5-1430-4fe3-b63d-996bb95ebc75@linux.dev> (raw)
In-Reply-To: <20251121231352.4032020-3-ameryhung@gmail.com>
On 11/21/25 3:13 PM, Amery Hung 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 nor 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 returned pointer, if not NULL, is
> guaranteed to be valid and point to a fully updated struct_ops struct.
> For struct_ops program reused in multiple struct_ops map, the return
> will be NULL.
>
> prog->aux->st_ops_assoc is protected by bumping the refcount for
> non-struct_ops programs and RCU for struct_ops programs. Since it would
> be inefficient to track programs associated with a struct_ops map, every
> non-struct_ops program will bump the refcount of the map to make sure
> st_ops_assoc stays valid. For a struct_ops program, it is protected by
> RCU as map_free will wait for an RCU grace period before disassociating
> the program with the map. The helper must be called in BPF program
> context or RCU read-side critical section.
>
> struct_ops implementers should note that the struct_ops returned may not
> be initialized nor attached yet. The struct_ops implementer will be
> responsible for tracking and checking the state of the associated
> struct_ops map if the use case expects an initialized or attached
> struct_ops.
Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
next prev parent reply other threads:[~2025-12-02 5:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 23:13 [PATCH bpf-next v7 0/6] Support associating BPF programs with struct_ops Amery Hung
2025-11-21 23:13 ` [PATCH bpf-next v7 1/6] bpf: Allow verifier to fixup kernel module kfuncs Amery Hung
2025-11-25 23:54 ` Andrii Nakryiko
2025-11-21 23:13 ` [PATCH bpf-next v7 2/6] bpf: Support associating BPF program with struct_ops Amery Hung
2025-11-25 23:54 ` Andrii Nakryiko
2025-12-02 5:40 ` Martin KaFai Lau [this message]
2025-11-21 23:13 ` [PATCH bpf-next v7 3/6] libbpf: Add support for " Amery Hung
2025-11-22 0:58 ` bot+bpf-ci
2025-11-25 23:54 ` Andrii Nakryiko
2025-11-25 23:56 ` Amery Hung
2025-11-21 23:13 ` [PATCH bpf-next v7 4/6] selftests/bpf: Test BPF_PROG_ASSOC_STRUCT_OPS command Amery Hung
2025-11-22 0:22 ` Alexei Starovoitov
2025-11-22 0:34 ` Amery Hung
2025-11-21 23:13 ` [PATCH bpf-next v7 5/6] selftests/bpf: Test ambiguous associated struct_ops Amery Hung
2025-11-21 23:13 ` [PATCH bpf-next v7 6/6] selftests/bpf: Test getting associated struct_ops in timer callback Amery Hung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=569b74e5-1430-4fe3-b63d-996bb95ebc75@linux.dev \
--to=martin.lau@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@meta.com \
--cc=martin.lau@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.