public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Chengkaitao <pilgrimtao@gmail.com>
To: arnd@arndb.de, ast@kernel.org, ihor.solodrai@linux.dev,
	daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
	eddyz87@gmail.com, memxor@gmail.com, song@kernel.org,
	yonghong.song@linux.dev, jolsa@kernel.org,
	john.fastabend@gmail.com, pengdonglin@xiaomi.com
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	bpf@vger.kernel.org, Kaitao Cheng <chengkaitao@kylinos.cn>
Subject: [PATCH bpf-next 0/3] bpf: Refactor how the verifier matches kfunc checks
Date: Sat,  4 Apr 2026 01:08:54 +0800	[thread overview]
Message-ID: <20260403170900.58659-1-pilgrimtao@gmail.com> (raw)

From: Kaitao Cheng <chengkaitao@kylinos.cn>

The verifier contains a lot of logic like the following, scattered
everywhere, which makes the code harder and harder to maintain:

static bool is_bpf_rbtree_add_kfunc(u32 func_id)
{
	return func_id == special_kfunc_list[KF_bpf_rbtree_add] ||
	       func_id == special_kfunc_list[KF_bpf_rbtree_add_impl];
}

This series introduces a new approach: each is_bpf_*-style set can
place its entries in its own section (.BTF_ids.##sfx), and the linker
script merges those per-set sections into the main .BTF_ids section.

When merging subsections, the linker script inserts an end symbol
for each one, so we can derive how many entries each subsection
holds. The kernel can then walk the entries in a subsection and
get the same effect as calling an is_bpf_* helper.

With this we can drop the BTF_SET_END macro; BTF_ID-style macros
can live anywhere in a C file and are no longer tied to a strict
BTF_SET_START … BTF_ID … BTF_SET_END ordering. On top of that,
all BTF_ID-style macros can eventually be consolidated in a uniform
way.

The current patch only partially migrates the rbtree kfuncs. If this
direction looks reasonable, I can continue with further migrations.

The end goal is something like module_init(): adding a new module
(kfunc) would only need a single line at the end—like module_init
(BPF_VERIF_KFUNC_DEF) to perform all the upfront wiring. Another
benefit of BPF_VERIF_KFUNC_DEF is that it pushes us to untangle
messy verifier safety cases and make them modular, so they can be
expressed as parameters to BPF_VERIF_KFUNC_DEF.

Reaching that goal may still need:

1. Further migration of other kfuncs. One issue worth stating up front:
there will be many .BTF_ids.##sfx subsections, and a large fraction may
contain only a single entry. I think that is acceptable; avoiding it
would mean keeping some logic on the old special_kfunc_list path for
those cases.

2. Trying to unify other macro families (BTF_ID_*, BTF_KFUNCS_*, …);
the exact design still needs more thought.

Kaitao Cheng (3):
  bpf: Teach resolve_btfids about the setsc type
  bpf: Introduce BTF_SET/ID_SUB and BPF_VERIF_KFUNC_DEF
  bpf: classify rbtree kfuncs with BPF_VERIF_KFUNC_DEF sets

 include/asm-generic/btf_ids.lds.h | 26 +++++++++
 include/asm-generic/vmlinux.lds.h |  2 +
 include/linux/btf_ids.h           | 92 +++++++++++++++++++++++++++----
 kernel/bpf/helpers.c              |  7 +++
 kernel/bpf/verifier.c             | 44 +++++----------
 tools/bpf/resolve_btfids/main.c   | 89 +++++++++++++++++++++++++++++-
 tools/include/linux/btf_ids.h     | 83 +++++++++++++++++++++++++---
 7 files changed, 292 insertions(+), 51 deletions(-)
 create mode 100644 include/asm-generic/btf_ids.lds.h

-- 
2.43.0


             reply	other threads:[~2026-04-03 17:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-03 17:08 Chengkaitao [this message]
2026-04-03 17:08 ` [PATCH bpf-next 1/3] bpf: Teach resolve_btfids about the setsc type Chengkaitao
2026-04-03 17:08 ` [PATCH bpf-next 2/3] bpf: Introduce BTF_SET/ID_SUB and BPF_VERIF_KFUNC_DEF Chengkaitao
2026-04-03 17:08 ` [PATCH bpf-next 3/3] bpf: classify rbtree kfuncs with BPF_VERIF_KFUNC_DEF sets Chengkaitao
2026-04-10  2:22 ` [PATCH bpf-next 0/3] bpf: Refactor how the verifier matches kfunc checks Chengkaitao

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=20260403170900.58659-1-pilgrimtao@gmail.com \
    --to=pilgrimtao@gmail.com \
    --cc=andrii@kernel.org \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=chengkaitao@kylinos.cn \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=pengdonglin@xiaomi.com \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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