From: sashiko-bot@kernel.org
To: "Yonghong Song" <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 03/11] bpf: Wire up JIT support for 16-byte kfunc returns
Date: Fri, 14 Aug 2026 01:20:39 +0000 [thread overview]
Message-ID: <20260814012040.1F4921F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813200225.1994805-1-yonghong.song@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The verifier fails to initialize BPF_REG_2 for 16-byte kfunc returns, and completely fails to initialize both BPF_REG_0 and BPF_REG_2 if the kfunc returns a 16-byte struct.
--
--- Patch [3]: [PATCH bpf-next v5 03/11] bpf: Wire up JIT support for 16-byte kfunc returns ---
commit fc27c41d2405fa63fb5ef7aa5e34586ccf98e0bd
Author: Yonghong Song <yonghong.song@linux.dev>
bpf: Wire up JIT support for 16-byte kfunc returns
This commit adds JIT support for 16-byte kfunc returns by placing the
second half of the return value in the BPF R2 register. It introduces
architecture-specific capabilities and enables support for x86-64, arm64,
and riscv64. The verifier is also updated to reject unsupported 16-byte
returns.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 57d14480ded29..161d77791bc62 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -2854,6 +2854,18 @@ int bpf_add_kfunc_call(struct bpf_verifier_env *env, u32 func_id, u16 offset)
> err = btf_distill_func_proto(&env->log, kfunc.btf, kfunc.proto, kfunc.name, &func_model);
> if (err)
> return err;
> + if (func_model.ret_size > 8) {
> + if (kfunc.flags && (*kfunc.flags & KF_FASTCALL)) {
> + verbose(env, "kfunc %s with >8-byte return is not supported with KF_FASTCALL\n",
> + kfunc.name);
> + return -EOPNOTSUPP;
> + }
> + if (!bpf_jit_supports_kfunc_ret_reg_pair()) {
> + verbose(env, "kfunc %s with >8-byte return is not supported by JIT\n",
> + kfunc.name);
> + return -EOPNOTSUPP;
> + }
> + }
[Severity: High]
Does the verifier need updates in check_kfunc_call() to track the initialization
of BPF_REG_2 for these larger returns?
When evaluating the kfunc return type in check_kfunc_call(), the verifier
currently appears to miss marking BPF_REG_2 as initialized for 16-byte scalar
returns:
kernel/bpf/verifier.c:check_kfunc_call() {
if (btf_type_is_scalar(t)) {
mark_reg_unknown(env, regs, BPF_REG_0);
...
} else if (btf_type_is_ptr(t)) {
...
} else if (btf_type_is_void(t)) {
...
}
}
Furthermore, if the kfunc returns a 16-byte struct, the code falls through
completely without initializing either BPF_REG_0 or BPF_REG_2.
Since all CALLER_SAVED_REGS are cleared to NOT_INIT earlier during the call,
won't this cause the verifier to incorrectly reject valid BPF programs that
attempt to read these return values?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813200210.1991507-1-yonghong.song@linux.dev?part=3
next prev parent reply other threads:[~2026-08-14 1:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 20:02 [PATCH bpf-next v5 00/11] bpf: Support aggregate return values up to 16 bytes Yonghong Song
2026-08-13 20:02 ` [PATCH bpf-next v5 01/11] bpf: Factor check_global_ret_scalar_reg() out of the global return check Yonghong Song
2026-08-13 20:02 ` [PATCH bpf-next v5 02/11] bpf: Add helpers to describe the R0:R2 return register pair Yonghong Song
2026-08-13 21:11 ` bot+bpf-ci
2026-08-13 20:02 ` [PATCH bpf-next v5 03/11] bpf: Wire up JIT support for 16-byte kfunc returns Yonghong Song
2026-08-14 1:20 ` sashiko-bot [this message]
2026-08-13 20:02 ` [PATCH bpf-next v5 04/11] bpf: Track R2 of register-pair returns in precision backtracking Yonghong Song
2026-08-13 20:49 ` bot+bpf-ci
2026-08-13 20:02 ` [PATCH bpf-next v5 05/11] bpf: Account R2 of register-pair returns in live register analysis Yonghong Song
2026-08-14 1:50 ` sashiko-bot
2026-08-13 20:02 ` [PATCH bpf-next v5 06/11] bpf: Add verifier support for 16-byte returns in R0:R2 Yonghong Song
2026-08-13 21:11 ` bot+bpf-ci
2026-08-14 2:26 ` sashiko-bot
2026-08-13 20:02 ` [PATCH bpf-next v5 07/11] bpf: Enable aggregate return types up to 16 bytes Yonghong Song
2026-08-13 20:02 ` [PATCH bpf-next v5 08/11] bpf: Reject register-pair returns when the subprog BTF is unreliable Yonghong Song
2026-08-13 20:49 ` bot+bpf-ci
2026-08-14 3:02 ` sashiko-bot
2026-08-13 20:02 ` [PATCH bpf-next v5 09/11] selftests/bpf: Add C tests for 16-byte returns in R0:R2 Yonghong Song
2026-08-13 21:11 ` bot+bpf-ci
2026-08-13 20:03 ` [PATCH bpf-next v5 10/11] selftests/bpf: Add inline-asm and subprog tests for R0:R2 returns Yonghong Song
2026-08-13 21:11 ` bot+bpf-ci
2026-08-13 20:03 ` [PATCH bpf-next v5 11/11] Documentation/bpf: Document up to 16-byte kfunc return values in R0:R2 Yonghong Song
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=20260814012040.1F4921F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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