Re: [PATCH AUTOSEL 7.0-5.10] bpf: Do not increment tailcall count when prog is NULL

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] Incomplete fix creating BPF architectural divergence: the tail call counter is still incremented before the NULL check in multiple BPF JIT implementations.
--

commit df5323d5a23d7d76d6c427c88e1a292e4d37a90e
Author: Hari Bathini <hbathini@linux.ibm.com>

bpf: Do not increment tailcall count when prog is NULL

This commit updates the BPF interpreter to increment the tail call
counter only after verifying the target program exists. This prevents
failing tail calls from exhausting the limit.

Link: https://lore.kernel.org/r/20260220062959.195101-1-hbathini@linux.ibm.com

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 7b675a451ec8e..67eb12b637a5d 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -2087,12 +2087,12 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn)
>  		if (unlikely(tail_call_cnt >= MAX_TAIL_CALL_CNT))
>  			goto out;
>  
> -		tail_call_cnt++;
> -
>  		prog = READ_ONCE(array->ptrs[index]);
>  		if (!prog)
>  			goto out;
>  
> +		tail_call_cnt++;
> +

Does this change introduce a semantic divergence between the BPF
interpreter and various BPF JIT implementations?

While this updates the interpreter, multiple JIT implementations (such as
x86-32, ARM32, s390x, and RISC-V 64) appear to still modify the tail call
counter before performing the prog == NULL check.

For example, if the JIT generated code updates the counter before the NULL
check, and does not revert it on the fall-through path, the counter will
remain modified.

Will a BPF program making many failed tail calls now exhaust its 33-call
limit when JIT-compiled on these architectures, but not when running under
the interpreter?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260420132314.1023554-191-sashal@kernel.org?part=1