Re: [PATCH bpf v2 2/2] selftests/bpf: Add socket filter attach test

[Puranjay Mohan <puranjay12@gmail.com>]

On Thu, Aug 14, 2025 at 6:06 PM Eduard Zingerman <eddyz87@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 <eddyz87@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.wan@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