On Thu, Aug 14, 2025 at 6:06 PM Eduard Zingerman <eddy...@gmail.com> wrote: > > 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.
Hi Eduard, You were right, I have verified that the program is hitting the 0xfff boundary while doing the call to bpf_skb_load_helper_32 While jiting this call, emit_a32_mov_i(tmp[1], func, ctx); is called, where this issue it triggered. The offset in imm_offset() is calculated as: ctx->offsets[ctx->prog->len - 1] * 4 + ctx->prologue_bytes + ctx->epilogue_bytes + imm_i * 4 For this program, ctx->offsets[ctx->prog->len - 1] * 4 itself is 0x1400 which is above 0xfff boundary. So, this is not a bug and expected behaviour with the current implementation of the JIT. For now, we can merge this and later I will try to improve the JIT so it works for bigger programs. Thanks, Puranjay
