[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250731210950.3927649-1-ameryhung@gmail.com>
Date: Thu, 31 Jul 2025 14:09:47 -0700
From: Amery Hung <ameryhung@...il.com>
To: bpf@...r.kernel.org
Cc: netdev@...r.kernel.org,
alexei.starovoitov@...il.com,
andrii@...nel.org,
daniel@...earbox.net,
tj@...nel.org,
memxor@...il.com,
martin.lau@...nel.org,
ameryhung@...il.com,
kernel-team@...a.com
Subject: [PATCH bpf-next v1 0/3] Allow struct_ops to get bpf_map during
This patchset allows struct_ops implementors to access bpf_map during
reg() and unreg() so that they can create an id to struct_ops instance
mapping. This in turn allows struct_ops kfuncs to refer to the instance
without passing a pointer to the struct_ops. The selftest provides an
end-to-end example.
Some struct_ops users extend themselves with other bpf programs, which
also need to call struct_ops kfuncs. For example, scx_layered uses
syscall bpf programs as a scx_layered specific control plane and uses
tracing programs to get additional information for scheduling [0].
The kfuncs may need to refer to the struct_ops instance and perform
jobs accordingly. To allow calling struct_ops kfuncs referring to
specific instances from different program types and context (e.g.,
struct_ops, tracing, async callbacks), the traditional way is to pass
the struct_ops pointer to kfuncs.
This patchset provides an alternative way, through a combination of
bpf map id and global variable. First, a struct_ops implementor will
use the map id of the struct_ops map as the id of an instance. Then,
it needs to maintain an id to instance mapping: inserting a new mapping
during reg() and removing it during unreg(). The map id can be acquired
by calling bpf_struct_ops_get(), which is tweaked to return bpf_map
instead of bool.
[0] https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_layered/src/bpf/main.bpf.c
Amery Hung (3):
bpf: Allow getting bpf_map from struct_ops kdata
selftests/bpf: Add multi_st_ops that supports multiple instances
selftests/bpf: Test multi_st_ops and calling kfuncs from different
programs
include/linux/bpf.h | 4 +-
kernel/bpf/bpf_struct_ops.c | 7 +-
.../test_struct_ops_id_ops_mapping.c | 77 ++++++++++++
.../bpf/progs/struct_ops_id_ops_mapping1.c | 57 +++++++++
.../bpf/progs/struct_ops_id_ops_mapping2.c | 57 +++++++++
.../selftests/bpf/test_kmods/bpf_testmod.c | 112 ++++++++++++++++++
.../selftests/bpf/test_kmods/bpf_testmod.h | 8 ++
.../bpf/test_kmods/bpf_testmod_kfunc.h | 2 +
8 files changed, 319 insertions(+), 5 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/test_struct_ops_id_ops_mapping.c
create mode 100644 tools/testing/selftests/bpf/progs/struct_ops_id_ops_mapping1.c
create mode 100644 tools/testing/selftests/bpf/progs/struct_ops_id_ops_mapping2.c
--
2.47.3
Powered by blists - more mailing lists