From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D8EBD242938; Tue, 23 Sep 2025 07:34:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758612883; cv=none; b=po0r8e9jKs2lJcaaGLmqVXh9AS+bZiynsZHSSgWkx6+0WSB9piQwuZEp4DVUlx7zNiB5UWeGwBGfQQLJHQ2e5VSP6f7CCvrRIqCF/2VfaboH4Jtsl/xNMU73brPFZK8OWhZ6uKXd0Tfth9dshXVRcj/TcMR5YooxI6GFLwwZlho= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758612883; c=relaxed/simple; bh=hpwsI3FdxZKmmkhnouyPb8s1V33yJi/17bA4ZtYmFEI=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=AAhS96OS+WZjnj5YE7SFH/MA1qahzcorZAMht9GbuoeZR6LCvSOug2+85fYA7/hEB2m2ZXiiNhz4Wn5Q3Ep10wiNWO36MjgVuIXL5QiJmuCrf5X+53kKdxkNi9a+DQV2uNL5o/9FiiXsucKLRhNn+NrPZ3QGtfyPsad70QU5yIw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4cWBYN6W1lztTWp; Tue, 23 Sep 2025 15:33:44 +0800 (CST) Received: from kwepemf100007.china.huawei.com (unknown [7.202.181.221]) by mail.maildlp.com (Postfix) with ESMTPS id CF8AA1800B1; Tue, 23 Sep 2025 15:34:37 +0800 (CST) Received: from [10.67.109.184] (10.67.109.184) by kwepemf100007.china.huawei.com (7.202.181.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 23 Sep 2025 15:34:36 +0800 Message-ID: <97c8e410-5482-42cc-85e1-5c22bfd1d192@huawei.com> Date: Tue, 23 Sep 2025 15:34:35 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] riscv: bpf: Fix uninitialized symbol 'retval_off' Content-Language: en-US To: Chenghao Duan , , , , , , , , CC: , , , , , , , , , , , , References: <20250922062244.822937-1-duanchenghao@kylinos.cn> <20250922062244.822937-2-duanchenghao@kylinos.cn> From: Pu Lehui In-Reply-To: <20250922062244.822937-2-duanchenghao@kylinos.cn> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemf100007.china.huawei.com (7.202.181.221) On 2025/9/22 14:22, Chenghao Duan wrote: > In the __arch_prepare_bpf_trampoline() function, retval_off is only > meaningful when save_ret is true, so the current logic is correct. > However, in the original logic, retval_off is only initialized under > certain conditions; for example, in the fmod_ret logic, the compiler is > not aware that the flags of the fmod_ret program (prog) have set > BPF_TRAMP_F_CALL_ORIG, which results in an uninitialized symbol > compilation warning. > > So initialize retval_off unconditionally to fix it. > > Signed-off-by: Chenghao Duan > --- > 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 9883a55d61b5..8475a8ab5715 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; Reviewed-by: Pu Lehui