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>
---
.../selftests/bpf/prog_tests/socket_filter.c | 124 ++++++++++++++++++
.../selftests/bpf/progs/socket_filter.c | 16 +++
2 files changed, 140 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/socket_filter.c
create mode 100644 tools/testing/selftests/bpf/progs/socket_filter.c
diff --git a/tools/testing/selftests/bpf/prog_tests/socket_filter.c b/tools/testing/selftests/bpf/prog_tests/socket_filter.c
new file mode 100644
index 000000000000..ee3a4cc1a992
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/socket_filter.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <test_progs.h>
+#include <sys/utsname.h>
+#include <uapi/linux/filter.h>
+#include "socket_filter.skel.h"
+
+static int duration;
+
+void do_test(void)
+{
+ /* the filter below is the tcpdump filter:
+ * tcpdump "not ether host 3c37121a2b3c and not ether host 184ecbca2a3a \
+ * and not ether host 14130b4d3f47 and not ether host f0f61cf440b7 \
+ * and not ether host a84b4dedf471 and not ether host d022be17e1d7 \
+ * and not ether host 5c497967208b and not ether host 706655784d5b"
+ */
+ struct sock_filter code[] = {
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0x121a2b3c },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 60, 0, 0x00003c37 },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 2, 0x121a2b3c },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 56, 0, 0x00003c37 },
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0xcbca2a3a },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 52, 0, 0x0000184e },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 2, 0xcbca2a3a },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 48, 0, 0x0000184e },
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0x0b4d3f47 },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 44, 0, 0x00001413 },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 2, 0x0b4d3f47 },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 40, 0, 0x00001413 },
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0x1cf440b7 },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 36, 0, 0x0000f0f6 },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 2, 0x1cf440b7 },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 32, 0, 0x0000f0f6 },
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0x4dedf471 },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 28, 0, 0x0000a84b },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 2, 0x4dedf471 },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 24, 0, 0x0000a84b },
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0xbe17e1d7 },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 20, 0, 0x0000d022 },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 2, 0xbe17e1d7 },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 16, 0, 0x0000d022 },
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0x7967208b },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 12, 0, 0x00005c49 },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 2, 0x7967208b },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 8, 0, 0x00005c49 },
+ { 0x20, 0, 0, 0x00000008 },
+ { 0x15, 0, 2, 0x55784d5b },
+ { 0x28, 0, 0, 0x00000006 },
+ { 0x15, 4, 0, 0x00007066 },
+ { 0x20, 0, 0, 0x00000002 },
+ { 0x15, 0, 3, 0x55784d5b },
+ { 0x28, 0, 0, 0x00000000 },
+ { 0x15, 0, 1, 0x00007066 },
+ { 0x06, 0, 0, 0x00000000 },
+ { 0x06, 0, 0, 0x00040000 },
+ };
+ struct sock_fprog bpf = {
+ .len = ARRAY_SIZE(code),
+ .filter = code,
+ };
+ int ret, sock = 0;
+
+ sock = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
+ if (CHECK(sock < 0, "create socket", "errno %d\n", errno))
+ return;
+
+ ret = setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &bpf, sizeof(bpf));
+ CHECK(ret < 0, "attach filter", "errno %d\n", errno);
+
+ close(sock);
+}
+
+void test_socket_filter(void)
+{
+ struct socket_filter *skel;
+ struct utsname uts;
+ int err;
+
+ err = uname(&uts);
+ if (err < 0)
+ return;
+
+ skel = socket_filter__open_and_load();
+ if (!ASSERT_OK_PTR(skel, "skel_open"))
+ return;
+
+ /* The filter JIT fails on armv6 */
+ if (strncmp(uts.machine, "armv6", strlen("armv6")) == 0 &&
+ skel->kconfig->CONFIG_BPF_JIT_ALWAYS_ON)
+ test__skip();
+ else
+ do_test();
+
+ socket_filter__destroy(skel);
+}
diff --git a/tools/testing/selftests/bpf/progs/socket_filter.c b/tools/testing/selftests/bpf/progs/socket_filter.c
new file mode 100644
index 000000000000..f93623ec7ec0
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/socket_filter.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "vmlinux.h"
+#include <bpf/bpf_helpers.h>
+
+char _license[] SEC("license") = "GPL";
+
+extern bool CONFIG_BPF_JIT_ALWAYS_ON __kconfig __weak;
+
+/* This function is here to have CONFIG_BPF_JIT_ALWAYS_ON
+ * used and added to object BTF.
+ */
+int unused(void)
+{
+ return CONFIG_BPF_JIT_ALWAYS_ON ? 0 : 1;
+}
--
2.43.0On 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? [...] w0 ^= w0 w7 ^= w7 r6 = r1 r8 = *(u64 *)(r6 +200) r9 = *(u32 *)(r6 +112) r2 = *(u32 *)(r6 +116) w9 -= w2 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x121a2b3c goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x3c37 goto pc+446 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x121a2b3c goto pc+14 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x3c37 goto pc+417 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit w2 = -875943366 if r0 != r2 goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x184e goto pc+386 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit w2 = -875943366 if r0 != r2 goto pc+14 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x184e goto pc+356 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0xb4d3f47 goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x1413 goto pc+326 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0xb4d3f47 goto pc+14 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x1413 goto pc+297 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x1cf440b7 goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0xf0f6 goto pc+267 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x1cf440b7 goto pc+14 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0xf0f6 goto pc+238 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x4dedf471 goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0xa84b goto pc+208 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x4dedf471 goto pc+14 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0xa84b goto pc+179 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit w2 = -1105731113 if r0 != r2 goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0xd022 goto pc+148 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit w2 = -1105731113 if r0 != r2 goto pc+14 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0xd022 goto pc+118 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x7967208b goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x5c49 goto pc+88 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x7967208b goto pc+14 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x5c49 goto pc+59 r2 = r9 r2 -= 8 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +8) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 8 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x55784d5b goto pc+15 r2 = r9 r2 -= 6 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +6) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 6 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 == 0x7066 goto pc+29 r2 = r9 r2 -= 2 if r2 s< 0x4 goto pc+3 r0 = *(u32 *)(r8 +2) r0 = be32 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 2 call bpf_skb_load_helper_32 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x55784d5b goto pc+16 r2 = r9 if r2 s< 0x2 goto pc+3 r0 = *(u16 *)(r8 +0) r0 = be16 r0 goto pc+8 r1 = r6 r2 = r8 r3 = r9 r4 = 0 call bpf_skb_load_helper_16 if r0 s>= 0x0 goto pc+2 w0 ^= w0 exit if r0 != 0x7066 goto pc+2 w0 = 0 exit w0 = 262144 exit
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. Thanks, Puranjay
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.
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
On Mon, 2025-08-25 at 21:27 +0200, Puranjay Mohan wrote: [...] > 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. Hi Puranjay, Thank you for checking this! What do you think about this test case, do we need it in the suite? Best regards, Eduard
Eduard Zingerman <eddyz87@gmail.com> writes: > On Mon, 2025-08-25 at 21:27 +0200, Puranjay Mohan wrote: > > [...] > >> 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. > > Hi Puranjay, > > Thank you for checking this! > What do you think about this test case, do we need it in the suite? I don't think that we need this test as it is based on a missing feature in the JIT. Once the arm JIT is improved, this test will silently stop testing what it is supposed to test (fallback to interpreter). Thanks, Puranjay
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/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, 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 -- Thanks, KaFai
© 2016 - 2025 Red Hat, Inc.