[PATCH bpf-next] selftests/bpf: Account for zero extensions in patch list expectations

[PATCH bpf-next] selftests/bpf: Account for zero extensions in patch list expectations

[Hungyu Lin]

patch_list_insert_in_front() checks the translated instructions around
the call of an inlined bpf_loop() and its callback. On s390, the verifier
adds zero extensions after the two 32-bit register writes in the loop.
The call is therefore at instruction 25 rather than 23, and the later
instructions checked by the test are also shifted by two. The test
fails despite the call and jump offsets being correct.

Use the corresponding instruction indices on s390 and RISC-V, whose
JITs request explicit zero extensions. Keep the original expectations
for the other enabled architectures and retain all branch offset and
callback entry checks.

Fixes: 57fae4059380 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.4-rc1")
Link: https://github.com/kernel-patches/bpf/actions/runs/41696128762/job/126138168160
Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
 .../selftests/bpf/progs/verifier_patch_list.c  | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/tools/testing/selftests/bpf/progs/verifier_patch_list.c b/tools/testing/selftests/bpf/progs/verifier_patch_list.c
index 581b75b7b5c5..a9ad1dc56c3a 100644
--- a/tools/testing/selftests/bpf/progs/verifier_patch_list.c
+++ b/tools/testing/selftests/bpf/progs/verifier_patch_list.c
@@ -298,6 +298,23 @@ __arch_arm64
 __arch_riscv64
 __arch_loongarch
 __success
+/* The verifier adds two zero extensions for these JITs. */
+#if defined(__TARGET_ARCH_s390) || defined(__TARGET_ARCH_riscv)
+__xlated("25: call pc+7")
+__xlated("...")
+__xlated("32: exit")
+__xlated("33: r0 = ")
+__xlated("35: r0 = &(void __percpu *)(r0)")
+__xlated("36: r0 = *(u64 *)(r0 +0)")
+__xlated("37: if r0 != 0x0 goto pc+2")
+__xlated("38: r0 = 1")
+__xlated("39: exit")
+__xlated("40: r1 += -1")
+__xlated("...")
+__xlated("51: if r1 != 0x0 goto pc-12")
+__xlated("52: r0 = 0")
+__xlated("53: exit")
+#else
 __xlated("23: call pc+7")
 __xlated("...")
 __xlated("30: exit")
@@ -312,6 +329,7 @@ __xlated("...")
 __xlated("49: if r1 != 0x0 goto pc-12")
 __xlated("50: r0 = 0")
 __xlated("51: exit")
+#endif
 __naked void patch_list_insert_in_front(void)
 {
 	asm volatile (

base-commit: d4bf9e34e299e45af8da2b0457b0ac3efbd7ae8d
-- 
2.43.0

Re: [PATCH bpf-next] selftests/bpf: Account for zero extensions in patch list expectations

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

> selftests/bpf: Account for zero extensions in patch list expectations

TL;DR: Commit message only: the Fixes: tag names a merge commit rather than
the commit that introduced patch_list_insert_in_front(), and it lacks a
preceding blank line.

>     selftests/bpf: Account for zero extensions in patch list expectations
>
>     patch_list_insert_in_front() checks the translated instructions around
>     the call of an inlined bpf_loop() and its callback. On s390, the verifier
>     adds zero extensions after the two 32-bit register writes in the loop.
>     The call is therefore at instruction 25 rather than 23, and the later
>     instructions checked by the test are also shifted by two. The test
>     fails despite the call and jump offsets being correct.
>     Use the corresponding instruction indices on s390 and RISC-V, whose
>     JITs request explicit zero extensions. Keep the original expectations
>     for the other enabled architectures and retain all branch offset and
>     callback entry checks.
>     Fixes: 57fae4059380 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.4-rc1")
>     Link: https://github.com/kernel-patches/bpf/actions/runs/41696128762/job/126138168160
>     Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>

The Fixes: tag names 57fae4059380, which is a merge commit.  Should it name
the commit that introduced patch_list_insert_in_front() instead?

  Fixes: d86e6695cb2f ("selftests/bpf: Test the tables that follow patched and removed instructions")

Also, the Fixes: line follows the body paragraph directly.  Could a blank
line be added between them?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/41728315768

Re: [PATCH bpf-next] selftests/bpf: Account for zero extensions in patch list expectations

[Alexei Starovoitov]

On Tue, Nov 03, 2026 at 01:53 PM Hungyu Lin <dennylin0707@gmail.com> wrote:
> patch_list_insert_in_front() checks the translated instructions around
> the call of an inlined bpf_loop() and its callback. On s390, the verifier
> adds zero extensions after the two 32-bit register writes in the loop.

Thanks a bunch. Applied.

But could you follow up to
remove the two 32-bit writes from inline_bpf_loop().
'w7 = 0' and 'r7 = 0' do the same thing.
'w0 = -E2BIG' is an old bug. bpf_loop() returns long.
The helper returns 0xfffffffffffffff9.
The inlined code returns 0xfffffff9.
So 'long ret = bpf_loop(...); if (ret < 0)' misses the error.
The "over max limit" check in prog_tests/bpf_loop.c doesn't see it.
The prog keeps the result in an int.

No other insn of this prog writes 32 bits.
With 64-bit writes the xlated code is the same on all five archs.
Then no need for the #if and the second copy of the expectations.

Something like this (compile tested only):

diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
index 6b719a2..321624a 100644
--- a/kernel/bpf/fixups.c
+++ b/kernel/bpf/fixups.c
@@ -2783,7 +2783,7 @@ static int inline_bpf_loop(struct bpf_verifier_env *env, int position,
 	 * expected number of iterations is too big.
 	 */
 	insn_buf[cnt++] = BPF_JMP_IMM(BPF_JLE, BPF_REG_1, BPF_MAX_LOOPS, 2);
-	insn_buf[cnt++] = BPF_MOV32_IMM(BPF_REG_0, -E2BIG);
+	insn_buf[cnt++] = BPF_MOV64_IMM(BPF_REG_0, -E2BIG);
 	insn_buf[cnt++] = BPF_JMP_IMM(BPF_JA, 0, 0, 16);
 	/* spill R6, R7, R8 to use these as loop vars */
 	insn_buf[cnt++] = BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_6, r6_offset);
@@ -2791,7 +2791,7 @@ static int inline_bpf_loop(struct bpf_verifier_env *env, int position,
 	insn_buf[cnt++] = BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_8, r8_offset);
 	/* initialize loop vars */
 	insn_buf[cnt++] = BPF_MOV64_REG(reg_loop_max, BPF_REG_1);
-	insn_buf[cnt++] = BPF_MOV32_IMM(reg_loop_cnt, 0);
+	insn_buf[cnt++] = BPF_MOV64_IMM(reg_loop_cnt, 0);
 	insn_buf[cnt++] = BPF_MOV64_REG(reg_loop_ctx, BPF_REG_3);
 	/* loop header,
 	 * if reg_loop_cnt >= reg_loop_max skip the loop body

Re: [PATCH bpf-next] selftests/bpf: Account for zero extensions in patch list expectations

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Tue,  3 Nov 2026 21:53:09 +0000 you wrote:
> patch_list_insert_in_front() checks the translated instructions around
> the call of an inlined bpf_loop() and its callback. On s390, the verifier
> adds zero extensions after the two 32-bit register writes in the loop.
> The call is therefore at instruction 25 rather than 23, and the later
> instructions checked by the test are also shifted by two. The test
> fails despite the call and jump offsets being correct.
> 
> [...]

Here is the summary with links:
  - [bpf-next] selftests/bpf: Account for zero extensions in patch list expectations
    https://git.kernel.org/bpf/bpf-next/c/8fb43ffc3327

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html