[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250821025532.GA287128@chenghao-pc>
Date: Thu, 21 Aug 2025 10:55:32 +0800
From: Chenghao Duan <duanchenghao@...inos.cn>
To: Pu Lehui <pulehui@...wei.com>
Cc: ast@...nel.org, bjorn@...nel.org, puranjay@...nel.org,
paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev,
eddyz87@...il.com, song@...nel.org, yonghong.song@...ux.dev,
john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, alex@...ti.fr,
bpf@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: bpf: Fix uninitialized symbol 'retval_off'
On Thu, Aug 21, 2025 at 09:58:20AM +0800, Pu Lehui wrote:
>
>
> On 2025/8/20 18:35, Chenghao Duan wrote:
> > On Wed, Aug 20, 2025 at 06:10:07PM +0800, Pu Lehui wrote:
> > >
> > >
> > > On 2025/8/20 17:26, Chenghao Duan wrote:
> > > > On Wed, Aug 20, 2025 at 02:52:01PM +0800, Pu Lehui wrote:
> > > > >
> > > > >
> > > > > On 2025/8/20 14:25, Chenghao Duan wrote:
> > > > > > In __arch_prepare_bpf_trampoline(), retval_off is only meaningful when
> > > > > > save_ret is true, so the current logic is correct. However, in the
>
> OK, I think we should make commit msg more explicit. Such like the follow.
> wdyt?
>
> `However, in the fmod_ret logic, the compiler is not aware that the flags of
> the fmod_ret prog have set BPF_TRAMP_F_CALL_ORIG, resulting in an
> uninitialized symbol compilation warning.`
>
Good idea
> > > > >
> > > > > lgtm, and same for `ip_off`, pls patch it together.
> > > >
> > > > I also checked at the time that ip_off is only initialized and assigned
> > > > when flags & BPF_TRAMP_F_IP_ARG is true. However, I noticed that the use
> > > > of ip_off also requires this condition, so the compiler did not issue a
> > > > warning.
> > > >
> > > > Chenghao
> > > >
> > > > >
> > > > > > original logic, retval_off is only initialized under certain
> > >
> > > Can you show how to replay this warning? I guess the warning path is as
> > > follow. Compiler didn't know fmod_ret prog need BPF_TRAMP_F_CALL_ORIG.
> > >
> > > ```
> > > if (fmod_ret->nr_links) {
> > > ...
> > > emit_sd(RV_REG_FP, -retval_off, RV_REG_ZERO, ctx);
> > > }
> > > ```
> > >
> >
> > Exactly, the compiler sees the unconditional use of retval_off.
> >
> > Chenghao
> >
> > > > > > conditions, which may cause a build warning.
> > > > > >
> > > > > > So initialize retval_off unconditionally to fix it.
> > > > > >
> > > > > > Signed-off-by: Chenghao Duan <duanchenghao@...inos.cn>
> > > > > > ---
> > > > > > arch/riscv/net/bpf_jit_comp64.c | 5 ++---
> > > > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
> > > > > > index 10e01ff06312..49bbda8372b0 100644
> > > > > > --- a/arch/riscv/net/bpf_jit_comp64.c
> > > > > > +++ b/arch/riscv/net/bpf_jit_comp64.c
> > > > > > @@ -1079,10 +1079,9 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
> > > > > > stack_size += 16;
> > > > > > save_ret = flags & (BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_RET_FENTRY_RET);
> > > > > > - if (save_ret) {
> > > > > > + if (save_ret)
> > > > > > stack_size += 16; /* Save both A5 (BPF R0) and A0 */
> > > > > > - retval_off = stack_size;
> > > > > > - }
> > > > > > + retval_off = stack_size;
> > > > > > stack_size += nr_arg_slots * 8;
> > > > > > args_off = stack_size;
Powered by blists - more mailing lists