From: Kui-Feng Lee <sinquersw@gmail.com>
To: thinker.li@gmail.com, bpf@vger.kernel.org, ast@kernel.org,
martin.lau@linux.dev, song@kernel.org, kernel-team@meta.com,
andrii@kernel.org, drosen@google.com
Cc: kuifeng@meta.com
Subject: Re: [PATCH bpf-next v12 00/14] Registrating struct_ops types from modules
Date: Fri, 8 Dec 2023 16:28:58 -0800 [thread overview]
Message-ID: <86d43141-5776-4070-918d-10c424a70d3f@gmail.com> (raw)
In-Reply-To: <20231207013950.1689269-1-thinker.li@gmail.com>
I have sent v13 to solve the conflictions with the latest for-next.
On 12/6/23 17:39, thinker.li@gmail.com wrote:
> From: Kui-Feng Lee <thinker.li@gmail.com>
>
> Given the current constraints of the current implementation,
> struct_ops cannot be registered dynamically. This presents a
> significant limitation for modules like coming fuse-bpf, which seeks
> to implement a new struct_ops type. To address this issue, a new API
> is introduced that allows the registration of new struct_ops types
> from modules.
>
> Previously, struct_ops types were defined in bpf_struct_ops_types.h
> and collected as a static array. The new API lets callers add new
> struct_ops types dynamically. The static array has been removed and
> replaced by the per-btf struct_ops_tab.
>
> The struct_ops subsystem relies on BTF to determine the layout of
> values in a struct_ops map and identify the subsystem that the
> struct_ops map registers to. However, the kernel BTF does not include
> the type information of struct_ops types defined by a module. The
> struct_ops subsystem requires knowledge of the corresponding module
> for a given struct_ops map and the utilization of BTF information from
> that module. We empower libbpf to determine the correct module for
> accessing the BTF information and pass an identity (FD) of the module
> btf to the kernel. The kernel looks up type information and registered
> struct_ops types directly from the given btf.
>
> If a module exits while one or more struct_ops maps still refer to a
> struct_ops type defined by the module, it can lead to unforeseen
> complications. Therefore, it is crucial to ensure that a module
> remains intact as long as any struct_ops map is still linked to a
> struct_ops type defined by the module. To achieve this, every
> struct_ops map holds a reference to the module while being registered.
>
> Changes from v11:
>
> - bpf_struct_ops_maps hold only the refcnt to the module, but not
> btf. (patch 1)
>
> - Fix warning messages. (patch 1, 9 and 10)
>
> - Remove unnecessary conditional compiling of CONFIG_BPF_JIT.
> (patch 4, 9 and 10)
>
> - Fix the commit log of the patch 7 to explain how a btf is pass from
> the user space and how the kernel handle it.
>
> - bpf_struct_ops_maps hold the module defining it's type, but not
> btf. A map will hold the module through its life-span from
> allocating to being free. (patch 8)
>
> - Change selftests and tracing __bpf_struct_ops_map_free() to wait
> for the release of the bpf_testmod module.
>
> - Include btf_obj_id in bpf_map_info. (patch 14)
>
> Changes from v10:
>
> - Guard btf.c from CONFIG_BPF_JIT=n. This patchset has introduced
> symbols from bpf_struct_ops.c which is only built when
> CONFIG_BPF_JIT=y.
>
> - Fix the warning of unused errout_free label by moving code that is
> leaked to patch 8 to patch 7.
>
> Changes from v9:
>
> - Remove the call_rcu_tasks_trace() changes from kern_sync_rcu().
>
> - Trace btf_put() in the test case to ensure the release of kmod's
> btf, or the consequent tests may fail for using kmod's unloaded old
> btf instead the new one created after loading again. The kmod's btf
> may live for awhile after unloading the kmod, for a map being freed
> asynchronized is still holding the btf.
>
> - Split "add struct_ops_tab to btf" into tow patches by adding
> "make struct_ops_map support btfs other than btf_vmlinux".
>
> - Flip the order of "pass attached BTF to the bpf_struct_ops
> subsystem" and "hold module for bpf_struct_ops_map" to make it more
> reasonable.
>
> - Fix the compile errors of a missing header file.
>
> Changes from v8:
>
> - Rename bpf_struct_ops_init_one() to bpf_struct_ops_desc_init().
>
> - Move code that using BTF_ID_LIST to the newly added patch 2.
>
> - Move code that lookup struct_ops types from a given module to the
> newly added patch 5.
>
> - Store the pointers of btf at st_maps.
>
> - Add test cases for the cases of modules being unload.
>
> - Call bpf_struct_ops_init() in btf_add_struct_ops() to fix an
> inconsistent issue.
>
> Changes from v7:
>
> - Fix check_struct_ops_btf_id() to use attach btf if there is instead
> of btf_vmlinux.
>
> Changes from v6:
>
> - Change returned error code to -EINVAL for the case of
> bpf_try_get_module().
>
> - Return an error code from bpf_struct_ops_init().
>
> - Fix the dependency issue of testing_helpers.c and
> rcu_tasks_trace_gp.skel.h.
>
> Changes from v5:
>
> - As the 2nd patch, we introduce "bpf_struct_ops_desc". This change
> involves moving certain members of "bpf_struct_ops" to
> "bpf_struct_ops_desc", which becomes a part of
> "btf_struct_ops_tab". This ensures that these members remain
> accessible even when the owner module of a "bpf_struct_ops" is
> unloaded.
>
> - Correct the order of arguments when calling
> in the 3rd patch.
>
> - Remove the owner argument from bpf_struct_ops_init_one(). Instead,
> callers should fill in st_ops->owner.
>
> - Make sure to hold the owner module when calling
> bpf_struct_ops_find() and bpf_struct_ops_find_value() in the 6th
> patch.
>
> - Merge the functions register_bpf_struct_ops_btf() and
> register_bpf_struct_ops() into a single function and relocate it to
> btf.c for better organization and clarity.
>
> - Undo the name modifications made to find_kernel_btf_id() and
> find_ksym_btf_id() in the 8th patch.
>
> Changes from v4:
>
> - Fix the dependency between testing_helpers.o and
> rcu_tasks_trace_gp.skel.h.
>
> Changes from v3:
>
> - Fix according to the feedback for v3.
>
> - Change of the order of arguments to make btf as the first
> argument.
>
> - Use btf_try_get_module() instead of try_get_module() since the
> module pointed by st_ops->owner can gone while some one is still
> holding its btf.
>
> - Move variables defined by BPF_STRUCT_OPS_COMMON_VALUE to struct
> bpf_struct_ops_common_value to validation easier.
>
> - Register the struct_ops type defined by bpf_testmod in its init
> function.
>
> - Rename field name to 'value_type_btf_obj_fd' to make it explicit.
>
> - Fix leaking of btf objects on error.
>
> - st_maps hold their modules to keep modules alive and prevent they
> from unloading.
>
> - bpf_map of libbpf keeps mod_btf_fd instead of a pointer to module_btf.
>
> - Do call_rcu_tasks_trace() in kern_sync_rcu() to ensure the
> bpf_testmod is unloaded properly. It uses rcu_tasks_trace_gp to
> trigger call_rcu_tasks_trace() in the kernel.
>
> - Merge and reorder patches in a reasonable order.
>
>
> Changes from v2:
>
> - Remove struct_ops array, and add a per-btf (module) struct_ops_tab
> to collect registered struct_ops types.
>
> - Validate value_type by checking member names and types.
>
> ---
> v11: https://lore.kernel.org/all/20231106201252.1568931-1-thinker.li@gmail.com/
> v10: https://lore.kernel.org/all/20231103232202.3664407-1-thinker.li@gmail.com/
> v9: https://lore.kernel.org/all/20231101204519.677870-1-thinker.li@gmail.com/
> v8: https://lore.kernel.org/all/20231030192810.382942-1-thinker.li@gmail.com/
> v7: https://lore.kernel.org/all/20231027211702.1374597-1-thinker.li@gmail.com/
> v6: https://lore.kernel.org/all/20231022050335.2579051-11-thinker.li@gmail.com/
> v5: https://lore.kernel.org/all/20231017162306.176586-1-thinker.li@gmail.com/
> v4: https://lore.kernel.org/all/20231013224304.187218-1-thinker.li@gmail.com/
> v3: https://lore.kernel.org/all/20230920155923.151136-1-thinker.li@gmail.com/
> v2: https://lore.kernel.org/all/20230913061449.1918219-1-thinker.li@gmail.com/
>
> Kui-Feng Lee (14):
> bpf: refactory struct_ops type initialization to a function.
> bpf: get type information with BPF_ID_LIST
> bpf, net: introduce bpf_struct_ops_desc.
> bpf: add struct_ops_tab to btf.
> bpf: make struct_ops_map support btfs other than btf_vmlinux.
> bpf: lookup struct_ops types from a given module BTF.
> bpf: pass attached BTF to the bpf_struct_ops subsystem
> bpf: hold module for bpf_struct_ops_map.
> bpf: validate value_type
> bpf, net: switch to dynamic registration
> libbpf: Find correct module BTFs for struct_ops maps and progs.
> bpf: export btf_ctx_access to modules.
> selftests/bpf: test case for register_bpf_struct_ops().
> bpf: pass btf object id in bpf_map_info.
>
> include/linux/bpf.h | 55 ++-
> include/linux/bpf_verifier.h | 1 +
> include/linux/btf.h | 8 +
> include/uapi/linux/bpf.h | 7 +-
> kernel/bpf/bpf_struct_ops.c | 421 ++++++++++--------
> kernel/bpf/bpf_struct_ops_types.h | 12 -
> kernel/bpf/btf.c | 124 +++++-
> kernel/bpf/syscall.c | 4 +-
> kernel/bpf/verifier.c | 25 +-
> net/bpf/bpf_dummy_struct_ops.c | 22 +-
> net/ipv4/bpf_tcp_ca.c | 22 +-
> tools/include/uapi/linux/bpf.h | 7 +-
> tools/lib/bpf/bpf.c | 4 +-
> tools/lib/bpf/bpf.h | 5 +-
> tools/lib/bpf/libbpf.c | 38 +-
> .../selftests/bpf/bpf_testmod/bpf_testmod.c | 52 +++
> .../selftests/bpf/bpf_testmod/bpf_testmod.h | 5 +
> .../bpf/prog_tests/test_struct_ops_module.c | 92 ++++
> .../selftests/bpf/progs/struct_ops_module.c | 30 ++
> .../selftests/bpf/progs/testmod_unload.c | 25 ++
> 20 files changed, 726 insertions(+), 233 deletions(-)
> delete mode 100644 kernel/bpf/bpf_struct_ops_types.h
> create mode 100644 tools/testing/selftests/bpf/prog_tests/test_struct_ops_module.c
> create mode 100644 tools/testing/selftests/bpf/progs/struct_ops_module.c
> create mode 100644 tools/testing/selftests/bpf/progs/testmod_unload.c
>
prev parent reply other threads:[~2023-12-09 0:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 1:39 [PATCH bpf-next v12 00/14] Registrating struct_ops types from modules thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 01/14] bpf: refactory struct_ops type initialization to a function thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 02/14] bpf: get type information with BPF_ID_LIST thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 03/14] bpf, net: introduce bpf_struct_ops_desc thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 04/14] bpf: add struct_ops_tab to btf thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 05/14] bpf: make struct_ops_map support btfs other than btf_vmlinux thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 06/14] bpf: lookup struct_ops types from a given module BTF thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 07/14] bpf: pass attached BTF to the bpf_struct_ops subsystem thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 08/14] bpf: hold module for bpf_struct_ops_map thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 09/14] bpf: validate value_type thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 10/14] bpf, net: switch to dynamic registration thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 11/14] libbpf: Find correct module BTFs for struct_ops maps and progs thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 12/14] bpf: export btf_ctx_access to modules thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 13/14] selftests/bpf: test case for register_bpf_struct_ops() thinker.li
2023-12-07 1:39 ` [PATCH bpf-next v12 14/14] bpf: pass btf object id in bpf_map_info thinker.li
2023-12-09 0:28 ` Kui-Feng Lee [this message]
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=86d43141-5776-4070-918d-10c424a70d3f@gmail.com \
--to=sinquersw@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=drosen@google.com \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=thinker.li@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox