[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9cbdefd6-a757-44b3-a1db-69ca8117aacb@huawei.com>
Date: Thu, 21 Aug 2025 09:58:20 +0800
From: Pu Lehui <pulehui@...wei.com>
To: Chenghao Duan <duanchenghao@...inos.cn>
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 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.`
>>>>
>>>> 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