On Thu, 2025-08-14 at 13:23 +0200, Puranjay Mohan wrote: > On Thu, Aug 14, 2025 at 2:35 AM Eduard Zingerman <eddy...@gmail.com> wrote: > > > > On Wed, 2025-08-13 at 23:29 +0800, KaFai Wan wrote: > > > This test verifies socket filter attachment functionality on architectures > > > supporting either BPF JIT compilation or the interpreter. > > > > > > It specifically validates the fallback to interpreter behavior when JIT > > > fails, > > > particularly targeting ARMv6 devices with the following configuration: > > > # CONFIG_BPF_JIT_ALWAYS_ON is not set > > > CONFIG_BPF_JIT_DEFAULT_ON=y > > > > > > Signed-off-by: KaFai Wan <kafai....@linux.dev> > > > --- > > > > This test should not be landed as-is, first let's do an analysis for > > why the program fails to jit compile on arm. > > > > I modified kernel to dump BPF program before jit attempt, but don't > > see anything obviously wrong with it. The patch to get disassembly > > and disassembly itself with resolved kallsyms are attached. > > > > Can someone with access to ARM vm/machine take a looks at this? > > Puranjay, Xu, would you have some time? > > Hi Eduard, > Thanks for the email, I will look into it. > > Let me try to boot a kernel on ARMv6 qemu and reproduce this.
Thank you, Puranjay, While looking at the code yesterday I found a legit case for failing to jit on armv6: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/arch/arm/net/bpf_jit_32.c#n445 https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/arch/arm/net/bpf_jit_32.c#n2089 But attached program does not seem to be that big to hit 0xfff boundary.
