From: Yonghong Song <yonghong.song@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com
Subject: Re: [PATCH bpf-next v6 02/10] bpf: Add helpers to describe the R0:R2 return register pair
Date: Tue, 18 Aug 2026 20:41:38 -0700 [thread overview]
Message-ID: <25af2027-05cb-4559-a828-9bb421f1ad5a@linux.dev> (raw)
In-Reply-To: <dfb4d201de87590bbca4663ede19fd6c4044035a.camel@gmail.com>
On 8/18/26 12:53 PM, Eduard Zingerman wrote:
> On Tue, 2026-08-18 at 12:51 -0700, Eduard Zingerman wrote:
>> On Sun, 2026-08-16 at 21:21 -0700, Yonghong Song wrote:
>>
>> ...
>>
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index b3c474ba7140..f1f1268d29c6 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -385,27 +385,70 @@ bool bpf_subprog_is_global(const struct bpf_verifier_env *env, int subprog)
>> ...
>>
>>> +static int bpf_compute_subprog_ret_regs(struct bpf_verifier_env *env)
>>> +{
>>> + const struct btf *btf = env->prog->aux->btf;
>>> + const struct btf_type *type;
>>> + int subprog;
>>> + u32 size;
>>> +
>>> + if (!env->prog->jit_requested || bpf_prog_is_offloaded(env->prog->aux))
>>> + return 0;
>>> +
>>> + /*
>>> + * Skip the main program: its return value is the program's exit code,
>>> + * read out of R0, so it never uses the register pair. An extension does
>>> + * have a real prototype for subprog 0, but bpf_check_attach_target()
>>> + * refuses to replace a function returning more than 8 bytes.
>>> + */
>>> + for (subprog = 1; subprog < env->subprog_cnt; subprog++) {
>>> + type = subprog_ret_type(env, subprog);
>>> + /*
>>> + * This runs before btf_validate_return_type(), so apply the same
>>> + * type filter here.
>>> + */
>>> + if (!type || !(btf_type_is_struct(type) || btf_type_is_scalar(type)))
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> I still think that only !type check is necessary here:
> Actually: if (!type || !btf_type_is_void(type)) ...
> since btf_resolve_size() does not like void.
Thinking through. I think your above suggestion is correct.
In later patch "bpf: Enable aggregate return types up to 16 bytes", we have
btf_validate_return_type():
...
if (btf_type_is_void(t) || btf_type_is_int(t) || btf_is_any_enum(t))
return 0;
+ if (btf_type_is_struct(t) && t->size <= 16) {
+ /*
+ * A global function's caller models the return as an opaque
+ * scalar pair, so it may only return scalars by value. A local
+ * function is verified inline, so a pointer field stays tracked
+ * and needs no such restriction.
+ */
+ bool local_func = subprog && !is_global;
+
+ if (local_func || btf_type_is_scalar_struct(env, btf, t, 0))
+ return 0;
+ }
return -EOPNOTSUPP;
So only the above 'return 0' types are supported (void, int, enum, struct etc.).
In bpf_compute_subprog_ret_regs(), we only need valid type and type won't be void.
The 'void' type is for btf_resolve_size(). For other types, btf_validate_return_type()
will reject earlier.
>
>> - btf_resolve_size can handle any type
>> - BTF validation should guarantee that return type is not e.g. BTF_KIND_VAR
>> that would trigger -EINVAL
>> - for local subprograms verifier checks if r0/r2 bear compatible types anyway
>> - for global subprograms BTF compliance is enforced.
>>
>> Could you please explain why would you want to keep it here?
>>
>>> + continue;
>>> + if (verifier_bug_if(IS_ERR(btf_resolve_size(btf, type, &size)), env,
>>> + "cannot size return type of subprog %d", subprog))
>>> + return -EFAULT;
>>> + if (ret_regs_cnt(size) > 1) {
>>> + subprog_info(env, subprog)->ret_reg_pair = true;
>>> + env->prog->jit_required = 1;
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> }
>>>
>>> const char *bpf_subprog_name(const struct bpf_verifier_env *env, int subprog)
next prev parent reply other threads:[~2026-08-19 3:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 4:21 [PATCH bpf-next v6 00/10] bpf: Support aggregate return values up to 16 bytes Yonghong Song
2026-08-17 4:21 ` [PATCH bpf-next v6 01/10] bpf: Factor check_global_ret_scalar_reg() out of the global return check Yonghong Song
2026-08-17 4:21 ` [PATCH bpf-next v6 02/10] bpf: Add helpers to describe the R0:R2 return register pair Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 15:20 ` Yonghong Song
2026-08-18 19:51 ` Eduard Zingerman
2026-08-18 19:53 ` Eduard Zingerman
2026-08-19 3:41 ` Yonghong Song [this message]
2026-08-17 4:21 ` [PATCH bpf-next v6 03/10] bpf: Wire up JIT support for 16-byte kfunc returns Yonghong Song
2026-08-17 4:37 ` sashiko-bot
2026-08-17 15:25 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 04/10] bpf: Handle R2 as a return register in precision backtracking Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 15:27 ` Yonghong Song
2026-08-18 18:21 ` Eduard Zingerman
2026-08-17 4:22 ` [PATCH bpf-next v6 05/10] bpf: Account R2 of register-pair returns in live register analysis Yonghong Song
2026-08-17 4:43 ` sashiko-bot
2026-08-17 15:40 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 06/10] bpf: Add verifier support for 16-byte returns in R0:R2 Yonghong Song
2026-08-17 4:42 ` sashiko-bot
2026-08-17 15:46 ` Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 16:02 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 07/10] bpf: Enable aggregate return types up to 16 bytes Yonghong Song
2026-08-17 4:42 ` sashiko-bot
2026-08-17 16:12 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 08/10] selftests/bpf: Add C tests for 16-byte returns in R0:R2 Yonghong Song
2026-08-17 4:45 ` sashiko-bot
2026-08-17 16:32 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 09/10] selftests/bpf: Add inline-asm and subprog tests for R0:R2 returns Yonghong Song
2026-08-17 4:42 ` sashiko-bot
2026-08-17 16:53 ` Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 17:12 ` Yonghong Song
2026-08-18 20:05 ` Eduard Zingerman
2026-08-17 4:22 ` [PATCH bpf-next v6 10/10] 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=25af2027-05cb-4559-a828-9bb421f1ad5a@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.com \
/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