Re: [PATCH bpf-next v4 10/25] bpf: Extend liveness analysis to track stack argument slots

[Yonghong Song <yonghong.song@linux.dev>]

On 5/14/26 12:53 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Incorrect logging of stack argument slots in `arg_track_join`.
> --
>
> commit 5139934569dff44b05e1ee083e4eb084fdca15e3
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Extend liveness analysis to track stack argument slots
>
> This commit extends the BPF verifier's liveness analysis to correctly track
> stack argument slots. It expands tracking arrays to cover MAX_AT_TRACK_REGS
> and propagates the tracked state through function calls to prevent incorrectly
> poisoning stack slots derived from frame pointers passed through stack
> arguments. It also updates logging functions to expose these new stack
> argument states.
>
>> diff --git a/kernel/bpf/liveness.c b/kernel/bpf/liveness.c
>> index 13dc5ae44d2b5..7f4a0e4c2c49d 100644
>> --- a/kernel/bpf/liveness.c
>> +++ b/kernel/bpf/liveness.c
> [ ... ]
>
>> @@ -1630,7 +1705,7 @@ static int compute_subprog_args(struct bpf_verifier_env *env,
>>   				continue;
>>   			ti = target - start;
>>   
>> -			for (r = 0; r < MAX_BPF_REG; r++)
>> +			for (r = 0; r < MAX_AT_TRACK_REGS; r++)
>>   				changed |= arg_track_join(env, idx, target, r,
>>   							  &at_in[ti][r], at_out[r]);
> Is it possible this will misleadingly print stack argument slots as
> non-existent registers?
>
> Since compute_subprog_args() now iterates r up to MAX_AT_TRACK_REGS,
> arg_track_join() will receive r >= MAX_BPF_REG.
>
> Looking at arg_track_join():
>
> kernel/bpf/liveness.c:arg_track_join() {
>      ...
> 	if (r >= 0)
> 		verbose(env, "r%d: ", r);
> 	else
> 		verbose(env, "fp%+d: ", r * 8);
>      ...
> }
>
> It seems this will log stack argument slots as r11, r12, etc., in the
> BPF_LOG_LEVEL2 verifier log, rather than their proper designations (sa0 to
> sa5) like arg_track_log() and print_subprog_arg_access() do.
>
> Should arg_track_join() be updated to handle r >= MAX_BPF_REG to maintain
> consistent formatting?

Yes, you are right, for 'r >= 0' case, we should have r[0-10] and for r >= 11
we should use 'sa*' to indicate it is for stack arguments.
Will fix.