[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62bf28ac-c1fa-fc60-ce52-6d993a8a4bbf@linux.dev>
Date: Tue, 8 Nov 2022 15:12:30 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Yang Jihong <yangjihong1@...wei.com>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
song@...nel.org, yhs@...com, john.fastabend@...il.com,
kpsingh@...nel.org, sdf@...gle.com, haoluo@...gle.com,
jolsa@...nel.org, illusionist.neo@...il.com, linux@...linux.org.uk,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, mykolal@...com, shuah@...nel.org,
benjamin.tissoires@...hat.com, memxor@...il.com,
asavkov@...hat.com, delyank@...com, bpf@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH bpf v2 1/5] bpf: Adapt 32-bit return value kfunc for
32-bit ARM when zext extension
On 11/7/22 1:20 AM, Yang Jihong wrote:
> For ARM32 architecture, if data width of kfunc return value is 32 bits,
> need to do explicit zero extension for high 32-bit, insn_def_regno should
> return dst_reg for BPF_JMP type of BPF_PSEUDO_KFUNC_CALL. Otherwise,
> opt_subreg_zext_lo32_rnd_hi32 returns -EFAULT, resulting in BPF failure.
>
> Signed-off-by: Yang Jihong <yangjihong1@...wei.com>
> ---
> kernel/bpf/verifier.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 7f0a9f6cb889..bac37757ffca 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -2404,6 +2404,9 @@ static int insn_def_regno(const struct bpf_insn *insn)
> {
> switch (BPF_CLASS(insn->code)) {
> case BPF_JMP:
> + if (insn->src_reg == BPF_PSEUDO_KFUNC_CALL)
> + return insn->dst_reg;
This does not look right. A kfunc can return void. The btf type of the kfunc's
return value needs to be checked against "void" first?
Also, this will affect insn_has_def32(), does is_reg64 (called from
insn_has_def32) need to be adjusted also?
For patch 2, as replied earlier in v1, I would separate out the prog that does
__sk_buff->sk and use the uapi's bpf.h instead of vmlinux.h since it does not
need CO-RE.
This set should target for bpf-next instead of bpf.
> + fallthrough;
> case BPF_JMP32:
> case BPF_ST:
> return -1;
Powered by blists - more mailing lists