All of lore.kernel.org
 help / color / mirror / Atom feed
From: thinker.li@gmail.com
To: bpf@vger.kernel.org, ast@kernel.org, martin.lau@linux.dev,
	song@kernel.org, kernel-team@meta.com, andrii@kernel.org
Cc: sinquersw@gmail.com, kuifeng@meta.com,
	Kui-Feng Lee <thinker.li@gmail.com>
Subject: [RFC bpf-next v2 0/9] Registrating struct_ops types from modules
Date: Tue, 12 Sep 2023 23:14:40 -0700	[thread overview]
Message-ID: <20230913061449.1918219-1-thinker.li@gmail.com> (raw)

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 to the array dynamically.

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) to the kernel.

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, you can hold a
reference to the module for each struct_ops map.

Kui-Feng Lee (9):
  bpf: refactory struct_ops type initialization to a function.
  bpf: add register and unregister functions for struct_ops.
  bpf: attach a module BTF to a bpf_struct_ops
  bpf: use attached BTF to find correct type info of struct_ops progs.
  bpf: hold module for bpf_struct_ops_map.
  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().
  Comments and debug

 include/linux/bpf.h                           |  19 +-
 include/linux/btf.h                           |   1 +
 include/uapi/linux/bpf.h                      |   4 +
 kernel/bpf/bpf_struct_ops.c                   | 346 +++++++++++++-----
 kernel/bpf/btf.c                              |   3 +-
 kernel/bpf/syscall.c                          |   8 +-
 kernel/bpf/verifier.c                         |   4 +-
 tools/include/uapi/linux/bpf.h                |   4 +
 tools/lib/bpf/bpf.c                           |   3 +-
 tools/lib/bpf/bpf.h                           |   4 +-
 tools/lib/bpf/libbpf.c                        | 147 +++++---
 .../selftests/bpf/bpf_testmod/bpf_testmod.c   |  84 +++++
 .../selftests/bpf/bpf_testmod/bpf_testmod.h   |   5 +
 .../bpf/prog_tests/test_struct_ops_module.c   |  40 ++
 .../selftests/bpf/progs/struct_ops_module.c   |  30 ++
 15 files changed, 558 insertions(+), 144 deletions(-)
 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

-- 
2.34.1


             reply	other threads:[~2023-09-13  6:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13  6:14 thinker.li [this message]
2023-09-13  6:14 ` [RFC bpf-next v2 1/9] bpf: refactory struct_ops type initialization to a function thinker.li
2023-09-15 22:43   ` Martin KaFai Lau
2023-09-16  1:35     ` Kui-Feng Lee
2023-09-13  6:14 ` [RFC bpf-next v2 2/9] bpf: add register and unregister functions for struct_ops thinker.li
2023-09-16  0:05   ` Martin KaFai Lau
2023-09-16  1:14     ` Kui-Feng Lee
2023-09-18 18:47       ` Martin KaFai Lau
2023-09-18 20:40         ` Kui-Feng Lee
2023-09-13  6:14 ` [RFC bpf-next v2 3/9] bpf: attach a module BTF to a bpf_struct_ops thinker.li
2023-09-13  6:14 ` [RFC bpf-next v2 4/9] bpf: use attached BTF to find correct type info of struct_ops progs thinker.li
2023-09-13  6:14 ` [RFC bpf-next v2 5/9] bpf: hold module for bpf_struct_ops_map thinker.li
2023-09-13  6:14 ` [RFC bpf-next v2 6/9] libbpf: Find correct module BTFs for struct_ops maps and progs thinker.li
2023-09-13  6:14 ` [RFC bpf-next v2 7/9] bpf: export btf_ctx_access to modules thinker.li
2023-09-13  6:14 ` [RFC bpf-next v2 8/9] selftests/bpf: test case for register_bpf_struct_ops() thinker.li
2023-09-13  6:14 ` [RFC bpf-next v2 9/9] Comments and debug thinker.li

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=20230913061449.1918219-1-thinker.li@gmail.com \
    --to=thinker.li@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kuifeng@meta.com \
    --cc=martin.lau@linux.dev \
    --cc=sinquersw@gmail.com \
    --cc=song@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.