From: Chenghao Duan duanchenghao@kylinos.cn
[ Upstream commit d0bf7cd5df18466d969bb60e8890b74cf96081ca ]
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 duanchenghao@kylinos.cn Reviewed-by: Pu Lehui pulehui@huawei.com Link: https://lore.kernel.org/r/20250922062244.822937-2-duanchenghao@kylinos.cn Signed-off-by: Alexei Starovoitov ast@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What changed: The patch moves `retval_off = stack_size;` out of the `if (save_ret)` block so it’s always initialized. Previously `retval_off` was only assigned when `save_ret` was true. - Before: `retval_off` assigned only inside `if (save_ret) { ... }` - After: `retval_off` assigned unconditionally immediately after the optional `stack_size += 16` - Reference: arch/riscv/net/bpf_jit_comp64.c:1066
- Why it matters: `retval_off` is used in code paths not explicitly guarded by `save_ret`, which makes compilers think it can be used uninitialized and emit a warning (e.g., -Wmaybe-uninitialized), even though, logically, those paths only occur with flags that imply `save_ret` must be true. - Unconditional uses in fmod_ret path: - Zeroing return value slot: arch/riscv/net/bpf_jit_comp64.c:1157 - Loading return value: arch/riscv/net/bpf_jit_comp64.c:1163 - Unconditional uses in call-orig path: - Store original function’s return in reserved slot: arch/riscv/net/bpf_jit_comp64.c:1176 - Store BPF R0: arch/riscv/net/bpf_jit_comp64.c:1177 - Final restore guarded by `save_ret`, confirming the semantic intent: arch/riscv/net/bpf_jit_comp64.c:1209
- Bug scope and user impact: - This is a build correctness fix that eliminates spurious “maybe- uninitialized” warnings that can be promoted to errors in some configurations or toolchains. It does not change runtime behavior because the only meaningful use of `retval_off` (e.g., restoring return values) is already guarded by `save_ret`. When `save_ret` is false, `retval_off`’s value is ignored by the logic that matters. - The warning can affect users building with stricter warning settings or newer compilers; resolving it improves build reliability for RISC-V with BPF trampolines.
- Containment and risk: - The change is tiny and contained to a single file/function in the RISC-V BPF JIT trampoline. - No new features, APIs, or architectural changes; no functional logic changed for valid flag combinations. - Safe even if misused flags were ever passed: `retval_off` now has a defined value, avoiding UB from uninitialized use.
- Applicability to stable trees: - The affected pattern exists in stable series that have the RISC-V BPF trampoline (e.g., v6.6 shows the same conditional initialization, with unconditional uses later). See v6.6 code where `retval_off` is only set under `if (save_ret)` and is used in the fmod_ret block and call-orig sequence without an explicit `save_ret` guard, mirroring the warning scenario. - Mainline commit: d0bf7cd5df184 (“riscv: bpf: Fix uninitialized symbol 'retval_off'”). - Likely Fixes: 25ad10658dc10 (“riscv, bpf: Adapt bpf trampoline to optimized riscv ftrace framework”), which introduced the trampoline structure that uses `retval_off` this way.
- Stable criteria check: - Fixes a real build issue (warnings that can become errors). - Small, self-contained change in one function and one file. - No functional side effects; does not alter behavior except removing undefined initialization state. - Not a feature or refactor; low regression risk; localized to RISC-V BPF trampoline.
Conclusion: This is a good and safe candidate for backporting to all stable trees that include the RISC-V BPF trampoline code path (e.g., 6.6.y and newer where applicable).
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 9883a55d61b5b..8475a8ab57151 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;