On Thu, 2025-08-14 at 09:06 -0700, Eduard Zingerman 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/a... https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/arch/a...
But attached program does not seem to be that big to hit 0xfff boundary.
Hi Eduard, Puranjay
OpenWRT users reported several tests that aren't working properly, which may be helpful.
https://github.com/openwrt/openwrt/issues/19405#issuecomment-3121390534 https://github.com/openwrt/openwrt/issues/19405#issuecomment-3176820629