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 v4 02/13] bpf: Add helpers to describe the R0:R2 return register pair
Date: Thu, 13 Aug 2026 11:02:19 -0700 [thread overview]
Message-ID: <05b6d121-8d29-4aa2-ae04-9d18a4fef5b5@linux.dev> (raw)
In-Reply-To: <45edea4007f2b3b02caa34ed448060d43bf1f6c3.camel@gmail.com>
On 8/12/26 1:07 PM, Eduard Zingerman wrote:
> On Mon, 2026-08-10 at 17:09 -0700, Yonghong Song wrote:
>> LLVM 23 added support for returning a value in two registers for an
>> __int128, or a struct/union whose size is greater than 8 but not more than
>> 16 bytes: such a value comes back in the R0:R2 register pair, with R2
>> holding the upper half. See LLVM patches [1] and [2].
>>
>> Later patches teach the JIT, precision backtracking, live register analysis
>> and the verifier itself about that convention. All of them need to answer
>> the same question: does this subprogram return its value in a register
>> pair? Add the shared helpers up front so that those patches can be ordered
>> independently of each other:
>>
>> - subprog_ret_type() resolves a subprogram's BTF return type. It is
>> factored out of subprog_returns_void(). The verifier_bug_if(!func) and
>> !func_proto checks it replaces are redundant, since
>> check_btf_func_early() already rejects a func_info record whose type_id
>> is not a BTF_KIND_FUNC pointing at a BTF_KIND_FUNC_PROTO. A check on
>> prog->aux->{btf,func_info} is added instead: unlike
>> subprog_returns_void(), which is only used for global subprograms, later
>> callers ask about static subprograms too, and those may belong to a
>> program loaded without BTF.
>>
>> - ret_regs_cnt() maps the size of a return value to the number of
>> registers holding it.
>>
>> - bpf_ret_reg_pair() answers the question above. Its users query it at
>> every subprogram call and at every subprogram exit, that is once per
>> verifier state rather than once per subprogram, so the answer is
>> precomputed into bpf_subprog_info->ret_reg_pair by
>> bpf_compute_subprog_ret_regs() and the helper itself is a flag test.
>> It lives in bpf_verifier.h because kernel/bpf/backtrack.c and
>> kernel/bpf/liveness.c need it as well.
>>
>> bpf_compute_subprog_ret_regs() runs in bpf_check() right before
>> bpf_compute_live_registers(), which is the first of those users: by then
>> BTF func_info has been validated and the subprogram list is final.
>>
>> No functional change, bpf_ret_reg_pair() has no callers yet.
>>
>> [1] https://github.com/llvm/llvm-project/pull/190894
>> [2] https://github.com/llvm/llvm-project/pull/206876
>>
>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>> ---
> I still think that bpf_compute_live_registers() can be used to compute
> this information w/o the need to resort to BTF.
Maybe it is possible. I think current bpf_compute_subprog_ret_regs()
is more clear. In llvm23, we have true signatures for bpf programs, so
we should have precise return types for each subprogram.
>
> ...
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 40150390dd50..58a177d26c46 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -382,27 +382,57 @@ bool bpf_subprog_is_global(const struct bpf_verifier_env *env, int subprog)
>> return aux && aux[subprog].linkage == BTF_FUNC_GLOBAL;
>> }
>>
>> -static bool subprog_returns_void(struct bpf_verifier_env *env, int subprog)
>> +/* Return type of a subprogram, NULL if it cannot be resolved */
>> +static const struct btf_type *subprog_ret_type(struct bpf_verifier_env *env, int subprog)
>> {
>> - const struct btf_type *type, *func, *func_proto;
>> + const struct btf_type *func, *func_proto;
>> const struct btf *btf = env->prog->aux->btf;
>> u32 btf_id;
>>
>> + if (!btf || !env->prog->aux->func_info)
>> + return NULL;
>> +
>> btf_id = env->prog->aux->func_info[subprog].type_id;
>>
>> + /* Both already validated by prepare_btf_func() at prog load. */
>> func = btf_type_by_id(btf, btf_id);
>> - if (verifier_bug_if(!func, env, "btf_id %u not found", btf_id))
>> - return false;
>> -
>> func_proto = btf_type_by_id(btf, func->type);
>> - if (!func_proto)
>> - return false;
>>
>> - type = btf_type_skip_modifiers(btf, func_proto->type, NULL);
>> - if (!type)
>> - return false;
>> + return btf_type_skip_modifiers(btf, func_proto->type, NULL);
>> +}
>> +
>> +static bool subprog_returns_void(struct bpf_verifier_env *env, int subprog)
>> +{
>> + const struct btf_type *type = subprog_ret_type(env, subprog);
>>
>> - return btf_type_is_void(type);
>> + return type && btf_type_is_void(type);
>> +}
>> +
>> +/*
>> + * Number of registers holding a function return value: a value of up to 8
>> + * bytes is returned in R0, a value of more than 8 bytes and no more than 16
>> + * bytes (an __int128 or a struct/union of such size) is returned in the R0:R2
>> + * register pair, with R2 holding the upper half.
>> + */
>> +static u32 ret_regs_cnt(u32 size)
>> +{
>> + return size > 8 && size <= 16 ? 2 : 1;
>> +}
>> +
>> +/*
>> + * Resolve the return convention of every subprogram once, so that
>> + * bpf_ret_reg_pair() is a plain flag test on the hot paths that use it.
>> + */
>> +static void bpf_compute_subprog_ret_regs(struct bpf_verifier_env *env)
>> +{
>> + const struct btf_type *type;
>> + int subprog;
>> +
>> + for (subprog = 0; subprog < env->subprog_cnt; subprog++) {
>> + type = subprog_ret_type(env, subprog);
>> + if (type && (btf_type_is_struct(type) || btf_type_is_scalar(type)))
>> + subprog_info(env, subprog)->ret_reg_pair = ret_regs_cnt(type->size) > 1;
> Nit: there is a btf.c:btf_resolve_size() api function, it would be
> better to use it instead of calculating the size ad-hoc.
Will use btf_resolve_size() to get type size.
>
> Should the jit_required flag be set here instead of the main
> verification pass?
Indeed, this is much better.
>
>> + }
>> }
>>
>> static const char *subprog_name(const struct bpf_verifier_env *env, int subprog)
> ...
next prev parent reply other threads:[~2026-08-13 18:02 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 0:09 [PATCH bpf-next v4 00/13] bpf: Support aggregate return values up to 16 bytes Yonghong Song
2026-08-11 0:09 ` [PATCH bpf-next v4 01/13] bpf: Factor check_global_ret_scalar_reg() out of the global return check Yonghong Song
2026-08-11 0:09 ` [PATCH bpf-next v4 02/13] bpf: Add helpers to describe the R0:R2 return register pair Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 19:31 ` Yonghong Song
2026-08-12 20:07 ` Eduard Zingerman
2026-08-13 18:02 ` Yonghong Song [this message]
2026-08-11 0:09 ` [PATCH bpf-next v4 03/13] bpf: Wire up JIT support for 16-byte kfunc returns Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 19:48 ` Yonghong Song
2026-08-12 20:42 ` Eduard Zingerman
2026-08-11 0:09 ` [PATCH bpf-next v4 04/13] bpf: Track R2 of register-pair returns in precision backtracking Yonghong Song
2026-08-12 21:16 ` Eduard Zingerman
2026-08-13 18:04 ` Yonghong Song
2026-08-11 0:09 ` [PATCH bpf-next v4 05/13] bpf: Account R2 of register-pair returns in live register analysis Yonghong Song
2026-08-11 1:09 ` bot+bpf-ci
2026-08-12 19:55 ` Yonghong Song
2026-08-12 21:21 ` Eduard Zingerman
2026-08-13 18:05 ` Yonghong Song
2026-08-11 0:09 ` [PATCH bpf-next v4 06/13] bpf: Reject callbacks returning more than 8 bytes Yonghong Song
2026-08-12 21:41 ` Eduard Zingerman
2026-08-13 18:09 ` Yonghong Song
2026-08-11 0:09 ` [PATCH bpf-next v4 07/13] bpf: Add verifier support for 16-byte returns in R0:R2 Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 20:12 ` Yonghong Song
2026-08-12 22:12 ` Eduard Zingerman
2026-08-13 18:20 ` Yonghong Song
2026-08-11 0:09 ` [PATCH bpf-next v4 08/13] bpf: Reject register-pair returns when the subprog BTF is unreliable Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 20:26 ` Yonghong Song
2026-08-12 22:24 ` Eduard Zingerman
2026-08-13 18:22 ` Yonghong Song
2026-08-11 0:09 ` [PATCH bpf-next v4 09/13] bpf: Enable aggregate return types up to 16 bytes Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 20:29 ` Yonghong Song
2026-08-12 22:47 ` Eduard Zingerman
2026-08-13 18:23 ` Yonghong Song
2026-08-11 0:10 ` [PATCH bpf-next v4 10/13] selftests/bpf: Add C tests for 16-byte returns in R0:R2 Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 20:49 ` Yonghong Song
2026-08-12 23:15 ` Eduard Zingerman
2026-08-13 18:24 ` Yonghong Song
2026-08-11 0:10 ` [PATCH bpf-next v4 11/13] selftests/bpf: Add inline-asm and subprog tests for R0:R2 returns Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 21:08 ` Yonghong Song
2026-08-12 23:29 ` Eduard Zingerman
2026-08-13 18:25 ` Yonghong Song
2026-08-13 0:09 ` Eduard Zingerman
2026-08-11 0:10 ` [PATCH bpf-next v4 12/13] selftests/bpf: Add tests for callbacks returning more than 8 bytes Yonghong Song
2026-08-11 1:24 ` bot+bpf-ci
2026-08-12 21:22 ` Yonghong Song
2026-08-13 0:10 ` Eduard Zingerman
2026-08-13 18:27 ` Yonghong Song
2026-08-11 0:10 ` [PATCH bpf-next v4 13/13] 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=05b6d121-8d29-4aa2-ae04-9d18a4fef5b5@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 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.