On 11/6/23 12:12 PM, thinker.li@xxxxxxxxx wrote:
From: Kui-Feng Lee <thinker.li@xxxxxxxxx>
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 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.
Thanks for the patches and working on this feature.
One thing that still needs to check is the "bpftool struct_ops dump" support for
kmod's btf. The bpftool changes can be a followup. However, please check if the
current uapi has what it needs. A quick look is the userspace should be able to
find the kmod btf from the map_info->btf_vmlinux_value_type_id.
We discussed a bit offline on patch 8 about putting the btf and module refcnt
together in bpf_struct_ops_map_free (but before synchronize_rcu_mult) which
should further simplify patch 8 also. hope that will work out.
Looking forward to v12.
