A new test of tail call count limiting revealed that the interpreter
did in fact allow up to MAX_TAIL_CALL_CNT + 1 tail calls, whereas the
x86 JITs stopped at the intended MAX_TAIL_CALL_CNT. The interpreter was
fixed in commit b61a28cf11d61f512172e673b8f8c4a6c789b425 ("bpf: Fix
off-by-one in tail call count limiting"). This patch set fixes all
arch-specific JITs except for RISC-V.
For each of the affected JITs, the incorrect behaviour was verified
by running the test_bpf test suite in QEMU. After the fixes, the JITs
pass the tail call count limiting test.
I have not been able to test the RISC-V JITs due to the lack of a
working toolchain and QEMU setup. It is likely that the RISC-V JITs
have the off-by-one behaviour too. I have not verfied any of the NIC JITs.
Link: https://lore.kernel.org/bpf/20210728164741.350370-1-johan.almbladh@xxxxxxxxxxxxxxxxx/
Johan Almbladh (7):
arm: bpf: Fix off-by-one in tail call count limiting
arm64: bpf: Fix off-by-one in tail call count limiting
powerpc: bpf: Fix off-by-one in tail call count limiting
s390: bpf: Fix off-by-one in tail call count limiting
sparc: bpf: Fix off-by-one in tail call count limiting
mips: bpf: Fix off-by-one in tail call count limiting
x86: bpf: Fix comments on tail call count limiting
arch/arm/net/bpf_jit_32.c | 6 +++---
arch/arm64/net/bpf_jit_comp.c | 4 ++--
arch/mips/net/ebpf_jit.c | 4 ++--
arch/powerpc/net/bpf_jit_comp32.c | 4 ++--
arch/powerpc/net/bpf_jit_comp64.c | 4 ++--
arch/s390/net/bpf_jit_comp.c | 6 +++---
arch/sparc/net/bpf_jit_comp_64.c | 2 +-
arch/x86/net/bpf_jit_comp32.c | 6 +++---
8 files changed, 18 insertions(+), 18 deletions(-)
--
2.25.1
