On 2/16/26 10:08, Hari Bathini wrote:
Test whether tail call count is incorrectly accounted for, when the
tail call fails due to a missing BPF program.
Signed-off-by: Hari Bathini <[email protected]>
---
- powerpc64 BPF JIT has been incorrectly accounting for tailcall count
even when BPF program to tailcall into is missing. A simple change
to one of the tailcall selftests could have flagged it earlier.
https://lore.kernel.org/all/[email protected]/
tools/testing/selftests/bpf/progs/tailcall3.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/progs/tailcall3.c
b/tools/testing/selftests/bpf/progs/tailcall3.c
index f60bcd7b8d4b..204f19c30a3e 100644
--- a/tools/testing/selftests/bpf/progs/tailcall3.c
+++ b/tools/testing/selftests/bpf/progs/tailcall3.c
@@ -5,7 +5,7 @@
struct {
__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
- __uint(max_entries, 1);
+ __uint(max_entries, 2);
__uint(key_size, sizeof(__u32));
__uint(value_size, sizeof(__u32));
} jmp_table SEC(".maps");
@@ -23,6 +23,9 @@ int classifier_0(struct __sk_buff *skb)
SEC("tc")
int entry(struct __sk_buff *skb)
{
+ /* prog == NULL case */
+ bpf_tail_call_static(skb, &jmp_table, 1);
+
bpf_tail_call_static(skb, &jmp_table, 0);
return 0;
}
Seems like the x86_64 JIT passes this already, but the interpreter still
has:
if (unlikely(tail_call_cnt >= MAX_TAIL_CALL_CNT))
goto out;
tail_call_cnt++;
prog = READ_ONCE(array->ptrs[index]);
if (!prog)
goto out;
Should it be changed too? Regardless:
Reviewed-by: Ilya Leoshkevich <[email protected]>