* [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions
@ 2023-12-06 7:38 Hengqi Chen
2023-12-06 7:38 ` [PATCH 1/2] LoongArch: BPF: Don't sign extend function return value Hengqi Chen
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Hengqi Chen @ 2023-12-06 7:38 UTC (permalink / raw)
To: loongarch; +Cc: chenhuacai, yangtiezhu, hejinyang, hengqi.chen
As reported on mailing list ([0]), several BPF testcases could
triggered kernel panics like:
# ./test_progs -t cls_redirect
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
[ 30.938489] CPU 3 Unable to handle kernel paging request at virtual address fffffffffd814de0, era == ffff800002009fb8, ra == ffff800002009f9c
[ 30.939331] Oops[#1]:
[ 30.939513] CPU: 3 PID: 1260 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
[ 30.939732] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 30.939901] pc ffff800002009fb8 ra ffff800002009f9c tp 9000000104da4000 sp 9000000104da7ab0
[ 30.940038] a0 fffffffffd814de0 a1 9000000104da7a68 a2 0000000000000000 a3 9000000104da7c10
[ 30.940183] a4 9000000104da7c14 a5 0000000000000002 a6 0000000000000021 a7 00005555904d7f90
[ 30.940321] t0 0000000000000110 t1 0000000000000000 t2 fffffffffd814de0 t3 0004c4b400000000
[ 30.940456] t4 ffffffffffffffff t5 00000000c3f63600 t6 0000000000000000 t7 0000000000000000
[ 30.940590] t8 000000000006d803 u0 0000000000000020 s9 9000000104da7b10 s0 900000010504c200
[ 30.940727] s1 fffffffffd814de0 s2 900000010504c200 s3 9000000104da7c10 s4 9000000104da7ad0
[ 30.940866] s5 0000000000000000 s6 90000000030e65bc s7 9000000104da7b44 s8 90000000044f6fc0
[ 30.941015] ra: ffff800002009f9c bpf_prog_846803e5ae81417f_cls_redirect+0xa0/0x590
[ 30.941535] ERA: ffff800002009fb8 bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
[ 30.941696] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 30.942224] PRMD: 00000004 (PPLV0 +PIE -PWE)
[ 30.942330] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
[ 30.942453] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 30.942612] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[ 30.942764] BADV: fffffffffd814de0
[ 30.942854] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
[ 30.942974] Modules linked in:
[ 30.943078] Process test_progs (pid: 1260, threadinfo=00000000ce303226, task=000000007d10bb76)
[ 30.943306] Stack : 900000010a064000 90000000044f6fc0 9000000104da7b48 0000000000000000
[ 30.943495] 0000000000000000 9000000104da7c14 9000000104da7c10 900000010504c200
[ 30.943626] 0000000000000001 ffff80001b88c000 9000000104da7b70 90000000030e6668
[ 30.943785] 0000000000000000 9000000104da7b58 ffff80001b88c048 9000000003d05000
[ 30.943936] 900000000303ac88 0000000000000000 0000000000000000 9000000104da7b70
[ 30.944091] 0000000000000000 0000000000000001 0000000731eeab00 0000000000000000
[ 30.944245] ffff80001b88c000 0000000000000000 0000000000000000 54b99959429f83b8
[ 30.944402] ffff80001b88c000 90000000044f6fc0 9000000101d70000 ffff80001b88c000
[ 30.944538] 000000000000005a 900000010504c200 900000010a064000 900000010a067000
[ 30.944697] 9000000104da7d88 0000000000000000 9000000003d05000 90000000030e794c
[ 30.944852] ...
[ 30.944924] Call Trace:
[ 30.945120] [<ffff800002009fb8>] bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
[ 30.945650] [<90000000030e6668>] bpf_test_run+0x1ec/0x2f8
[ 30.945958] [<90000000030e794c>] bpf_prog_test_run_skb+0x31c/0x684
[ 30.946065] [<90000000026d4f68>] __sys_bpf+0x678/0x2724
[ 30.946159] [<90000000026d7288>] sys_bpf+0x20/0x2c
[ 30.946253] [<90000000032dd224>] do_syscall+0x7c/0x94
[ 30.946343] [<9000000002541c5c>] handle_syscall+0xbc/0x158
[ 30.946492]
[ 30.946549] Code: 0015030e 5c0009c0 5001d000 <28c00304> 02c00484 29c00304 00150009 2a42d2e4 0280200d
[ 30.946793]
[ 30.946971] ---[ end trace 0000000000000000 ]---
[ 32.093225] Kernel panic - not syncing: Fatal exception in interrupt
[ 32.093526] Kernel relocated by 0x2320000
[ 32.093630] .text @ 0x9000000002520000
[ 32.093725] .data @ 0x9000000003400000
[ 32.093792] .bss @ 0x9000000004413200
[ 34.971998] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
Tracking this down reveals two different code paths lead to
these panics.
1. Signed extend function return value
Take the `cls_redirect` test as an example, when subprog mode
is enabled, we have:
cls_redirect()
-> get_global_metrics() returns pcpu ptr 0xfffffefffc00b480
The pointer is later signed-extended to 0xfffffffffc00b480 at
`BPF_JMP | BPF_EXIT`. During BPF prog run, this triggers unhandled
page fault and a kernel panic.
The `verifier_map_ptr_mixing` test is another victim of this
signed-extension.
BPF verifier ensures all BPF progs loaded run to completion, so
every BPF prog has at least one `exit` instruction. Why do most of
them survive this signed-extension? That's because most BPF prog
types (if not all) return small non-negative integers, like TC or XDP.
Some prog types (like tracing) even ignore the return value.
In the above cases, we use subprogs, and subprogs return pointer
values, so bad things happened.
2. Signed extend memory load operand
The `cgrp_local_storage` test triggers panics when doing memory
load (see `cgrp_ls_tp_btf.c` for details):
ptr = bpf_cgrp_storage_get(&map_a, task->cgroups->dfl_cgrp, 0,
BPF_LOCAL_STORAGE_GET_F_CREATE);
The expression `task->cgroups->dfl_cgrp` involves two memory load.
Since the field offset fits in imm12 or imm14, we use ldd or ldptrd
to perform memory load. But the ldd and ldptrd instructions both
have the side effect that it will signed-extended the imm operand.
Finally, we got the wrong addresses and result in kernel panics.
Let's get rid of those fatal signed-extension instrutions to fix
these issues.
- For the first case, don't sext on return values like other arches.
- For the second case, we fallback to use a generic ldxd instruction.
[0]: https://lore.kernel.org/loongarch/CAEyhmHT6UOryPZi7eEfw01Y_CjAqxy8NM6eKkdvdojJqB9P7eQ@mail.gmail.com/
Hengqi Chen (2):
LoongArch: BPF: Don't sign extend function return value
LoongArch: BPF: Don't sign extend memory load operand
arch/loongarch/net/bpf_jit.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
--
2.34.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/2] LoongArch: BPF: Don't sign extend function return value
2023-12-06 7:38 [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Hengqi Chen
@ 2023-12-06 7:38 ` Hengqi Chen
2023-12-06 7:38 ` [PATCH 2/2] LoongArch: BPF: Don't sign extend memory load operand Hengqi Chen
2023-12-07 10:05 ` [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Huacai Chen
2 siblings, 0 replies; 6+ messages in thread
From: Hengqi Chen @ 2023-12-06 7:38 UTC (permalink / raw)
To: loongarch; +Cc: chenhuacai, yangtiezhu, hejinyang, hengqi.chen
The `cls_redirect` test triggers a kernel panic like:
# ./test_progs -t cls_redirect
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
[ 30.938489] CPU 3 Unable to handle kernel paging request at virtual address fffffffffd814de0, era == ffff800002009fb8, ra == ffff800002009f9c
[ 30.939331] Oops[#1]:
[ 30.939513] CPU: 3 PID: 1260 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
[ 30.939732] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 30.939901] pc ffff800002009fb8 ra ffff800002009f9c tp 9000000104da4000 sp 9000000104da7ab0
[ 30.940038] a0 fffffffffd814de0 a1 9000000104da7a68 a2 0000000000000000 a3 9000000104da7c10
[ 30.940183] a4 9000000104da7c14 a5 0000000000000002 a6 0000000000000021 a7 00005555904d7f90
[ 30.940321] t0 0000000000000110 t1 0000000000000000 t2 fffffffffd814de0 t3 0004c4b400000000
[ 30.940456] t4 ffffffffffffffff t5 00000000c3f63600 t6 0000000000000000 t7 0000000000000000
[ 30.940590] t8 000000000006d803 u0 0000000000000020 s9 9000000104da7b10 s0 900000010504c200
[ 30.940727] s1 fffffffffd814de0 s2 900000010504c200 s3 9000000104da7c10 s4 9000000104da7ad0
[ 30.940866] s5 0000000000000000 s6 90000000030e65bc s7 9000000104da7b44 s8 90000000044f6fc0
[ 30.941015] ra: ffff800002009f9c bpf_prog_846803e5ae81417f_cls_redirect+0xa0/0x590
[ 30.941535] ERA: ffff800002009fb8 bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
[ 30.941696] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 30.942224] PRMD: 00000004 (PPLV0 +PIE -PWE)
[ 30.942330] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
[ 30.942453] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 30.942612] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[ 30.942764] BADV: fffffffffd814de0
[ 30.942854] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
[ 30.942974] Modules linked in:
[ 30.943078] Process test_progs (pid: 1260, threadinfo=00000000ce303226, task=000000007d10bb76)
[ 30.943306] Stack : 900000010a064000 90000000044f6fc0 9000000104da7b48 0000000000000000
[ 30.943495] 0000000000000000 9000000104da7c14 9000000104da7c10 900000010504c200
[ 30.943626] 0000000000000001 ffff80001b88c000 9000000104da7b70 90000000030e6668
[ 30.943785] 0000000000000000 9000000104da7b58 ffff80001b88c048 9000000003d05000
[ 30.943936] 900000000303ac88 0000000000000000 0000000000000000 9000000104da7b70
[ 30.944091] 0000000000000000 0000000000000001 0000000731eeab00 0000000000000000
[ 30.944245] ffff80001b88c000 0000000000000000 0000000000000000 54b99959429f83b8
[ 30.944402] ffff80001b88c000 90000000044f6fc0 9000000101d70000 ffff80001b88c000
[ 30.944538] 000000000000005a 900000010504c200 900000010a064000 900000010a067000
[ 30.944697] 9000000104da7d88 0000000000000000 9000000003d05000 90000000030e794c
[ 30.944852] ...
[ 30.944924] Call Trace:
[ 30.945120] [<ffff800002009fb8>] bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
[ 30.945650] [<90000000030e6668>] bpf_test_run+0x1ec/0x2f8
[ 30.945958] [<90000000030e794c>] bpf_prog_test_run_skb+0x31c/0x684
[ 30.946065] [<90000000026d4f68>] __sys_bpf+0x678/0x2724
[ 30.946159] [<90000000026d7288>] sys_bpf+0x20/0x2c
[ 30.946253] [<90000000032dd224>] do_syscall+0x7c/0x94
[ 30.946343] [<9000000002541c5c>] handle_syscall+0xbc/0x158
[ 30.946492]
[ 30.946549] Code: 0015030e 5c0009c0 5001d000 <28c00304> 02c00484 29c00304 00150009 2a42d2e4 0280200d
[ 30.946793]
[ 30.946971] ---[ end trace 0000000000000000 ]---
[ 32.093225] Kernel panic - not syncing: Fatal exception in interrupt
[ 32.093526] Kernel relocated by 0x2320000
[ 32.093630] .text @ 0x9000000002520000
[ 32.093725] .data @ 0x9000000003400000
[ 32.093792] .bss @ 0x9000000004413200
[ 34.971998] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
This is because we signed-extend function return values.
When subprog mode is enabled, we have:
cls_redirect()
-> get_global_metrics() returns pcpu ptr 0xfffffefffc00b480
The pointer returned is later signed-extended to 0xfffffffffc00b480
at `BPF_JMP | BPF_EXIT`. During BPF prog run, this triggers unhandled
page fault and a kernel panic.
Drop the unnecessary signed-extension on return values like other
arches do.
With this change, we have:
# ./test_progs -t cls_redirect
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
#51/1 cls_redirect/cls_redirect_inlined:OK
#51/2 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK
#51/3 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK
#51/4 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK
#51/5 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK
#51/6 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK
#51/7 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK
#51/8 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK
#51/9 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK
#51/10 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK
#51/11 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK
#51/12 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK
#51/13 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK
#51/14 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK
#51/15 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK
#51/16 cls_redirect/cls_redirect_subprogs:OK
#51/17 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK
#51/18 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK
#51/19 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK
#51/20 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK
#51/21 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK
#51/22 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK
#51/23 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK
#51/24 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK
#51/25 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK
#51/26 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK
#51/27 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK
#51/28 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK
#51/29 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK
#51/30 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK
#51/31 cls_redirect/cls_redirect_dynptr:OK
#51/32 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK
#51/33 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK
#51/34 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK
#51/35 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK
#51/36 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK
#51/37 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK
#51/38 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK
#51/39 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK
#51/40 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK
#51/41 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK
#51/42 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK
#51/43 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK
#51/44 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK
#51/45 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK
#51 cls_redirect:OK
Summary: 1/45 PASSED, 0 SKIPPED, 0 FAILED
Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
---
arch/loongarch/net/bpf_jit.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
index 169ff8b3915e..0303c0094d38 100644
--- a/arch/loongarch/net/bpf_jit.c
+++ b/arch/loongarch/net/bpf_jit.c
@@ -911,8 +911,6 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, bool ext
/* function return */
case BPF_JMP | BPF_EXIT:
- emit_sext_32(ctx, regmap[BPF_REG_0], true);
-
if (i == ctx->prog->len - 1)
break;
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 2/2] LoongArch: BPF: Don't sign extend memory load operand
2023-12-06 7:38 [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Hengqi Chen
2023-12-06 7:38 ` [PATCH 1/2] LoongArch: BPF: Don't sign extend function return value Hengqi Chen
@ 2023-12-06 7:38 ` Hengqi Chen
2023-12-07 10:05 ` [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Huacai Chen
2 siblings, 0 replies; 6+ messages in thread
From: Hengqi Chen @ 2023-12-06 7:38 UTC (permalink / raw)
To: loongarch; +Cc: chenhuacai, yangtiezhu, hejinyang, hengqi.chen
The `cgrp_local_storage` test triggers a kernel panic like:
# ./test_progs -t cgrp_local_storage
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
[ 550.930632] CPU 1 Unable to handle kernel paging request at virtual address 0000000000000080, era == ffff80000200be34, ra == ffff80000200be00
[ 550.931781] Oops[#1]:
[ 550.931966] CPU: 1 PID: 1303 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
[ 550.932215] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 550.932403] pc ffff80000200be34 ra ffff80000200be00 tp 9000000108350000 sp 9000000108353dc0
[ 550.932545] a0 0000000000000000 a1 0000000000000517 a2 0000000000000118 a3 00007ffffbb15558
[ 550.932682] a4 00007ffffbb15620 a5 90000001004e7700 a6 0000000000000021 a7 0000000000000118
[ 550.932824] t0 ffff80000200bdc0 t1 0000000000000517 t2 0000000000000517 t3 00007ffff1c06ee0
[ 550.932961] t4 0000555578ae04d0 t5 fffffffffffffff8 t6 0000000000000004 t7 0000000000000020
[ 550.933097] t8 0000000000000040 u0 00000000000007b8 s9 9000000108353e00 s0 90000001004e7700
[ 550.933241] s1 9000000004005000 s2 0000000000000001 s3 0000000000000000 s4 0000555555eb2ec8
[ 550.933379] s5 00007ffffbb15bb8 s6 00007ffff1dafd60 s7 000055555663f610 s8 00007ffff1db0050
[ 550.933520] ra: ffff80000200be00 bpf_prog_98f1b9e767be2a84_on_enter+0x40/0x200
[ 550.933911] ERA: ffff80000200be34 bpf_prog_98f1b9e767be2a84_on_enter+0x74/0x200
[ 550.934105] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 550.934596] PRMD: 00000004 (PPLV0 +PIE -PWE)
[ 550.934712] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
[ 550.934836] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 550.934976] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[ 550.935097] BADV: 0000000000000080
[ 550.935181] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
[ 550.935291] Modules linked in:
[ 550.935391] Process test_progs (pid: 1303, threadinfo=000000006c3b1c41, task=0000000061f84a55)
[ 550.935643] Stack : 00007ffffbb15bb8 0000555555eb2ec8 0000000000000000 0000000000000001
[ 550.935844] 9000000004005000 ffff80001b864000 00007ffffbb15450 90000000029aa034
[ 550.935990] 0000000000000000 9000000108353ec0 0000000000000118 d07d9dfb09721a09
[ 550.936175] 0000000000000001 0000000000000000 9000000108353ec0 0000000000000118
[ 550.936314] 9000000101d46ad0 900000000290abf0 000055555663f610 0000000000000000
[ 550.936479] 0000000000000003 9000000108353ec0 00007ffffbb15450 90000000029d7288
[ 550.936635] 00007ffff1dafd60 000055555663f610 0000000000000000 0000000000000003
[ 550.936779] 9000000108353ec0 90000000035dd1f0 00007ffff1dafd58 9000000002841c5c
[ 550.936939] 0000000000000119 0000555555eea5a8 00007ffff1d78780 00007ffffbb153e0
[ 550.937083] ffffffffffffffda 00007ffffbb15518 0000000000000040 00007ffffbb15558
[ 550.937224] ...
[ 550.937299] Call Trace:
[ 550.937521] [<ffff80000200be34>] bpf_prog_98f1b9e767be2a84_on_enter+0x74/0x200
[ 550.937910] [<90000000029aa034>] bpf_trace_run2+0x90/0x154
[ 550.938105] [<900000000290abf0>] syscall_trace_enter.isra.0+0x1cc/0x200
[ 550.938224] [<90000000035dd1f0>] do_syscall+0x48/0x94
[ 550.938319] [<9000000002841c5c>] handle_syscall+0xbc/0x158
[ 550.938477]
[ 550.938607] Code: 580009ae 50016000 262402e4 <28c20085> 14092084 03a00084 16000024 03240084 00150006
[ 550.938851]
[ 550.939021] ---[ end trace 0000000000000000 ]---
[ 552.231492] note: test_progs[1303] exited with preempt_count 1
[ 552.233328] ------------[ cut here ]------------
[ 552.233789] Voluntary context switch within RCU read-side critical section!
[ 552.234047] WARNING: CPU: 0 PID: 1303 at kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x52c/0x58c
[ 552.234480] Modules linked in:
[ 552.234688] CPU: 0 PID: 1303 Comm: test_progs Tainted: G D 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
[ 552.234941] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 552.235953] pc 9000000002904304 ra 9000000002904304 tp 9000000108350000 sp 9000000108353900
[ 552.236201] a0 000000000000003f a1 90000000040f5198 a2 9000000108353728 a3 90000000040f51a0
[ 552.236360] a4 90000000040f5198 a5 9000000108353720 a6 0000000000000001 a7 0000000000000001
[ 552.236508] t0 d07d9dfb09721a09 t1 d07d9dfb09721a09 t2 0000000000000001 t3 0000000000000001
[ 552.236646] t4 0000000000000004 t5 0000000000000000 t6 0000000000000030 t7 0000000000000000
[ 552.236788] t8 0000000000038f70 u0 90000000039b3db0 s9 90000001083539f0 s0 900000009002a100
[ 552.236969] s1 90000001004e7700 s2 90000000036f2100 s3 90000001004e7700 s4 900000000417f530
[ 552.237149] s5 0000000000000000 s6 9000000108353a28 s7 9000000004005000 s8 0000000000000001
[ 552.237371] ra: 9000000002904304 rcu_note_context_switch+0x52c/0x58c
[ 552.237582] ERA: 9000000002904304 rcu_note_context_switch+0x52c/0x58c
[ 552.237755] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 552.237994] PRMD: 00000000 (PPLV0 -PIE -PWE)
[ 552.238169] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
[ 552.238347] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 552.238540] ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
[ 552.238689] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
[ 552.238841] CPU: 0 PID: 1303 Comm: test_progs Tainted: G D 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
[ 552.239108] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 552.239365] Stack : 0000000000000256 0000000000000000 9000000002844000 9000000108350000
[ 552.243185] 9000000108353550 9000000108353558 0000000000000000 9000000108353698
[ 552.243351] 9000000108353690 9000000108353690 90000001083534b0 0000000000000001
[ 552.243500] 0000000000000001 9000000108353558 d07d9dfb09721a09 90000001002d2100
[ 552.243707] 0000000000000001 0000000000000004 0000000000000000 0000000000000030
[ 552.243857] 0000000000000000 000000000003a604 000000008c938000 90000001083539f0
[ 552.244017] 0000000000000000 0000000000000000 90000000039e08b8 9000000004005000
[ 552.244206] 9000000002904304 0000000000000140 9000000108353a28 9000000004005000
[ 552.244376] 0000000000000001 0000000000000000 9000000002844018 9000000002904304
[ 552.244593] 00000000000000b0 0000000000000000 0000000000000000 0000000000071c1c
[ 552.244847] ...
[ 552.244981] Call Trace:
[ 552.245119] [<9000000002844018>] show_stack+0x64/0x188
[ 552.245463] [<90000000035dbf94>] dump_stack_lvl+0x60/0x88
[ 552.245575] [<9000000002862400>] __warn+0x8c/0x16c
[ 552.245665] [<900000000359b858>] report_bug+0x1a4/0x20c
[ 552.245762] [<90000000035dd090>] do_bp+0x1f0/0x308
[ 552.245919] [<9000000004751924>] exception_handlers+0x1924/0x10000
[ 552.246110] [<9000000002904304>] rcu_note_context_switch+0x52c/0x58c
[ 552.246278] [<90000000035e454c>] __schedule+0xa4/0xa88
[ 552.246381] [<90000000035e4f68>] schedule+0x38/0xe0
[ 552.246502] [<9000000002901354>] synchronize_rcu_expedited+0x400/0x84c
[ 552.246637] [<9000000002b7777c>] namespace_unlock+0xcc/0x16c
[ 552.246803] [<9000000002b7cf9c>] put_mnt_ns+0xbc/0xfc
[ 552.247004] [<900000000288f65c>] free_nsproxy+0x24/0x1c4
[ 552.247132] [<90000000028688d4>] do_exit+0x31c/0x914
[ 552.247283] [<9000000002868f80>] make_task_dead+0x94/0x164
[ 552.247428] [<900000000284426c>] die+0x110/0x134
[ 552.247523] [<90000000035edc38>] do_page_fault+0x1e0/0x394
[ 552.247624] [<900000000285601c>] tlb_do_page_fault_0+0x118/0x1b4
[ 552.247931] [<ffff80000200be00>] bpf_prog_98f1b9e767be2a84_on_enter+0x40/0x200
[ 552.248192] [<90000000029aa034>] bpf_trace_run2+0x90/0x154
[ 552.248328] [<900000000290abf0>] syscall_trace_enter.isra.0+0x1cc/0x200
[ 552.248459] [<90000000035dd1f0>] do_syscall+0x48/0x94
[ 552.248640] [<9000000002841c5c>] handle_syscall+0xbc/0x158
[ 552.248861]
[ 552.249017] ---[ end trace 0000000000000000 ]---
Further investigation shows that this panic is triggered by memory
load operations:
ptr = bpf_cgrp_storage_get(&map_a, task->cgroups->dfl_cgrp, 0,
BPF_LOCAL_STORAGE_GET_F_CREATE);
The expression `task->cgroups->dfl_cgrp` involves two memory load.
Since the field offset fits in imm12 or imm14, we use ldd or ldptrd
instructions. But both instructions have the side effect that it
will signed-extended the imm operand. Finally, we got the wrong
addresses and panics is inevitable.
Use a generic ldxd instruction to avoid this kind of issues.
With this change, we have:
# ./test_progs -t cgrp_local_storage
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
test_cgrp_local_storage:PASS:join_cgroup /cgrp_local_storage 0 nsec
#48/1 cgrp_local_storage/tp_btf:OK
test_attach_cgroup:PASS:skel_open 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
libbpf: prog 'update_cookie_tracing': failed to attach: ERROR: strerror_r(-524)=22
test_attach_cgroup:FAIL:prog_attach unexpected error: -524
#48/2 cgrp_local_storage/attach_cgroup:FAIL
test_recursion:PASS:skel_open_and_load 0 nsec
libbpf: prog 'on_lookup': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'on_lookup': failed to auto-attach: -524
test_recursion:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/3 cgrp_local_storage/recursion:FAIL
#48/4 cgrp_local_storage/negative:OK
#48/5 cgrp_local_storage/cgroup_iter_sleepable:OK
test_yes_rcu_lock:PASS:skel_open 0 nsec
test_yes_rcu_lock:PASS:skel_load 0 nsec
libbpf: prog 'yes_rcu_lock': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'yes_rcu_lock': failed to auto-attach: -524
test_yes_rcu_lock:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/6 cgrp_local_storage/yes_rcu_lock:FAIL
#48/7 cgrp_local_storage/no_rcu_lock:OK
#48 cgrp_local_storage:FAIL
All error logs:
test_cgrp_local_storage:PASS:join_cgroup /cgrp_local_storage 0 nsec
test_attach_cgroup:PASS:skel_open 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
libbpf: prog 'update_cookie_tracing': failed to attach: ERROR: strerror_r(-524)=22
test_attach_cgroup:FAIL:prog_attach unexpected error: -524
#48/2 cgrp_local_storage/attach_cgroup:FAIL
test_recursion:PASS:skel_open_and_load 0 nsec
libbpf: prog 'on_lookup': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'on_lookup': failed to auto-attach: -524
test_recursion:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/3 cgrp_local_storage/recursion:FAIL
test_yes_rcu_lock:PASS:skel_open 0 nsec
test_yes_rcu_lock:PASS:skel_load 0 nsec
libbpf: prog 'yes_rcu_lock': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'yes_rcu_lock': failed to auto-attach: -524
test_yes_rcu_lock:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/6 cgrp_local_storage/yes_rcu_lock:FAIL
#48 cgrp_local_storage:FAIL
Summary: 0/4 PASSED, 0 SKIPPED, 1 FAILED
No panics any more. (The test still failed because lack of BPF trampoline
which I am actively working on.)
Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
---
arch/loongarch/net/bpf_jit.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
index 0303c0094d38..d76281efc5b8 100644
--- a/arch/loongarch/net/bpf_jit.c
+++ b/arch/loongarch/net/bpf_jit.c
@@ -986,14 +986,8 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, bool ext
}
break;
case BPF_DW:
- if (is_signed_imm12(off)) {
- emit_insn(ctx, ldd, dst, src, off);
- } else if (is_signed_imm14(off)) {
- emit_insn(ctx, ldptrd, dst, src, off);
- } else {
- move_imm(ctx, t1, off, is32);
- emit_insn(ctx, ldxd, dst, src, t1);
- }
+ move_imm(ctx, t1, off, is32);
+ emit_insn(ctx, ldxd, dst, src, t1);
break;
}
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions
2023-12-06 7:38 [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Hengqi Chen
2023-12-06 7:38 ` [PATCH 1/2] LoongArch: BPF: Don't sign extend function return value Hengqi Chen
2023-12-06 7:38 ` [PATCH 2/2] LoongArch: BPF: Don't sign extend memory load operand Hengqi Chen
@ 2023-12-07 10:05 ` Huacai Chen
2023-12-07 14:49 ` Hengqi Chen
2 siblings, 1 reply; 6+ messages in thread
From: Huacai Chen @ 2023-12-07 10:05 UTC (permalink / raw)
To: Hengqi Chen; +Cc: loongarch, yangtiezhu, hejinyang
Hi, Hengqi and Tiezhu,
I applied both of your fixes, but ldsx_insn/ctx_member_sign_ext still
fails. However it passes in Hengqi's original commit message.
./test_progs -t ldsx_insn
test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec
test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec
libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524
test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected
error: -524 (errno 524)
#117/1 ldsx_insn/map_val and probed_memory:FAIL
(cgroup_helpers.c:97: errno: Invalid argument) Enabling controller
cpu: /mnt/cgroup.subtree_control
#117 ldsx_insn: Failed to setup cgroup environment
test_ctx_member_sign_ext:FAIL:join_cgroup /ldsx_test unexpected
join_cgroup /ldsx_test: actual -1 < expected 0
#117/2 ldsx_insn/ctx_member_sign_ext:FAIL
#117/3 ldsx_insn/ctx_member_narrow_sign_ext:OK
#117 ldsx_insn:FAIL
All error logs:
test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec
test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec
libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524
test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected
error: -524 (errno 524)
#117/1 ldsx_insn/map_val and probed_memory:FAIL
(cgroup_helpers.c:97: errno: Invalid argument) Enabling controller
cpu: /mnt/cgroup.subtree_control
#117 ldsx_insn: Failed to setup cgroup environment
test_ctx_member_sign_ext:FAIL:join_cgroup /ldsx_test unexpected
join_cgroup /ldsx_test: actual -1 < expected 0
#117/2 ldsx_insn/ctx_member_sign_ext:FAIL
#117 ldsx_insn:FAIL
Summary: 0/1 PASSED, 0 SKIPPED, 1 FAILED
Huacai
On Thu, Dec 7, 2023 at 1:53 PM Hengqi Chen <hengqi.chen@gmail.com> wrote:
>
> As reported on mailing list ([0]), several BPF testcases could
> triggered kernel panics like:
>
> # ./test_progs -t cls_redirect
> Can't find bpf_testmod.ko kernel module: -2
> WARNING! Selftests relying on bpf_testmod.ko will be skipped.
> [ 30.938489] CPU 3 Unable to handle kernel paging request at virtual address fffffffffd814de0, era == ffff800002009fb8, ra == ffff800002009f9c
> [ 30.939331] Oops[#1]:
> [ 30.939513] CPU: 3 PID: 1260 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
> [ 30.939732] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
> [ 30.939901] pc ffff800002009fb8 ra ffff800002009f9c tp 9000000104da4000 sp 9000000104da7ab0
> [ 30.940038] a0 fffffffffd814de0 a1 9000000104da7a68 a2 0000000000000000 a3 9000000104da7c10
> [ 30.940183] a4 9000000104da7c14 a5 0000000000000002 a6 0000000000000021 a7 00005555904d7f90
> [ 30.940321] t0 0000000000000110 t1 0000000000000000 t2 fffffffffd814de0 t3 0004c4b400000000
> [ 30.940456] t4 ffffffffffffffff t5 00000000c3f63600 t6 0000000000000000 t7 0000000000000000
> [ 30.940590] t8 000000000006d803 u0 0000000000000020 s9 9000000104da7b10 s0 900000010504c200
> [ 30.940727] s1 fffffffffd814de0 s2 900000010504c200 s3 9000000104da7c10 s4 9000000104da7ad0
> [ 30.940866] s5 0000000000000000 s6 90000000030e65bc s7 9000000104da7b44 s8 90000000044f6fc0
> [ 30.941015] ra: ffff800002009f9c bpf_prog_846803e5ae81417f_cls_redirect+0xa0/0x590
> [ 30.941535] ERA: ffff800002009fb8 bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
> [ 30.941696] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
> [ 30.942224] PRMD: 00000004 (PPLV0 +PIE -PWE)
> [ 30.942330] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
> [ 30.942453] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
> [ 30.942612] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
> [ 30.942764] BADV: fffffffffd814de0
> [ 30.942854] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
> [ 30.942974] Modules linked in:
> [ 30.943078] Process test_progs (pid: 1260, threadinfo=00000000ce303226, task=000000007d10bb76)
> [ 30.943306] Stack : 900000010a064000 90000000044f6fc0 9000000104da7b48 0000000000000000
> [ 30.943495] 0000000000000000 9000000104da7c14 9000000104da7c10 900000010504c200
> [ 30.943626] 0000000000000001 ffff80001b88c000 9000000104da7b70 90000000030e6668
> [ 30.943785] 0000000000000000 9000000104da7b58 ffff80001b88c048 9000000003d05000
> [ 30.943936] 900000000303ac88 0000000000000000 0000000000000000 9000000104da7b70
> [ 30.944091] 0000000000000000 0000000000000001 0000000731eeab00 0000000000000000
> [ 30.944245] ffff80001b88c000 0000000000000000 0000000000000000 54b99959429f83b8
> [ 30.944402] ffff80001b88c000 90000000044f6fc0 9000000101d70000 ffff80001b88c000
> [ 30.944538] 000000000000005a 900000010504c200 900000010a064000 900000010a067000
> [ 30.944697] 9000000104da7d88 0000000000000000 9000000003d05000 90000000030e794c
> [ 30.944852] ...
> [ 30.944924] Call Trace:
> [ 30.945120] [<ffff800002009fb8>] bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
> [ 30.945650] [<90000000030e6668>] bpf_test_run+0x1ec/0x2f8
> [ 30.945958] [<90000000030e794c>] bpf_prog_test_run_skb+0x31c/0x684
> [ 30.946065] [<90000000026d4f68>] __sys_bpf+0x678/0x2724
> [ 30.946159] [<90000000026d7288>] sys_bpf+0x20/0x2c
> [ 30.946253] [<90000000032dd224>] do_syscall+0x7c/0x94
> [ 30.946343] [<9000000002541c5c>] handle_syscall+0xbc/0x158
> [ 30.946492]
> [ 30.946549] Code: 0015030e 5c0009c0 5001d000 <28c00304> 02c00484 29c00304 00150009 2a42d2e4 0280200d
> [ 30.946793]
> [ 30.946971] ---[ end trace 0000000000000000 ]---
> [ 32.093225] Kernel panic - not syncing: Fatal exception in interrupt
> [ 32.093526] Kernel relocated by 0x2320000
> [ 32.093630] .text @ 0x9000000002520000
> [ 32.093725] .data @ 0x9000000003400000
> [ 32.093792] .bss @ 0x9000000004413200
> [ 34.971998] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
>
> Tracking this down reveals two different code paths lead to
> these panics.
>
> 1. Signed extend function return value
>
> Take the `cls_redirect` test as an example, when subprog mode
> is enabled, we have:
>
> cls_redirect()
> -> get_global_metrics() returns pcpu ptr 0xfffffefffc00b480
>
> The pointer is later signed-extended to 0xfffffffffc00b480 at
> `BPF_JMP | BPF_EXIT`. During BPF prog run, this triggers unhandled
> page fault and a kernel panic.
>
> The `verifier_map_ptr_mixing` test is another victim of this
> signed-extension.
>
> BPF verifier ensures all BPF progs loaded run to completion, so
> every BPF prog has at least one `exit` instruction. Why do most of
> them survive this signed-extension? That's because most BPF prog
> types (if not all) return small non-negative integers, like TC or XDP.
> Some prog types (like tracing) even ignore the return value.
> In the above cases, we use subprogs, and subprogs return pointer
> values, so bad things happened.
>
> 2. Signed extend memory load operand
>
> The `cgrp_local_storage` test triggers panics when doing memory
> load (see `cgrp_ls_tp_btf.c` for details):
>
> ptr = bpf_cgrp_storage_get(&map_a, task->cgroups->dfl_cgrp, 0,
> BPF_LOCAL_STORAGE_GET_F_CREATE);
>
> The expression `task->cgroups->dfl_cgrp` involves two memory load.
> Since the field offset fits in imm12 or imm14, we use ldd or ldptrd
> to perform memory load. But the ldd and ldptrd instructions both
> have the side effect that it will signed-extended the imm operand.
> Finally, we got the wrong addresses and result in kernel panics.
>
> Let's get rid of those fatal signed-extension instrutions to fix
> these issues.
> - For the first case, don't sext on return values like other arches.
> - For the second case, we fallback to use a generic ldxd instruction.
>
> [0]: https://lore.kernel.org/loongarch/CAEyhmHT6UOryPZi7eEfw01Y_CjAqxy8NM6eKkdvdojJqB9P7eQ@mail.gmail.com/
>
> Hengqi Chen (2):
> LoongArch: BPF: Don't sign extend function return value
> LoongArch: BPF: Don't sign extend memory load operand
>
> arch/loongarch/net/bpf_jit.c | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> --
> 2.34.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions
2023-12-07 10:05 ` [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Huacai Chen
@ 2023-12-07 14:49 ` Hengqi Chen
2023-12-08 0:48 ` Huacai Chen
0 siblings, 1 reply; 6+ messages in thread
From: Hengqi Chen @ 2023-12-07 14:49 UTC (permalink / raw)
To: Huacai Chen; +Cc: loongarch, yangtiezhu, hejinyang
Hi, Huacai,
On Thu, Dec 7, 2023 at 6:05 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> Hi, Hengqi and Tiezhu,
>
> I applied both of your fixes, but ldsx_insn/ctx_member_sign_ext still
> fails. However it passes in Hengqi's original commit message.
>
> ./test_progs -t ldsx_insn
>
Testing good on my side, no regression.
> test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec
> test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec
> libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22
> libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524
> test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected
> error: -524 (errno 524)
> #117/1 ldsx_insn/map_val and probed_memory:FAIL
> (cgroup_helpers.c:97: errno: Invalid argument) Enabling controller
> cpu: /mnt/cgroup.subtree_control
> #117 ldsx_insn: Failed to setup cgroup environment
> test_ctx_member_sign_ext:FAIL:join_cgroup /ldsx_test unexpected
> join_cgroup /ldsx_test: actual -1 < expected 0
It seems like it's related to your cgroup setup.
> #117/2 ldsx_insn/ctx_member_sign_ext:FAIL
> #117/3 ldsx_insn/ctx_member_narrow_sign_ext:OK
> #117 ldsx_insn:FAIL
>
> All error logs:
> test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec
> test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec
> libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22
> libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524
> test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected
> error: -524 (errno 524)
> #117/1 ldsx_insn/map_val and probed_memory:FAIL
> (cgroup_helpers.c:97: errno: Invalid argument) Enabling controller
> cpu: /mnt/cgroup.subtree_control
> #117 ldsx_insn: Failed to setup cgroup environment
> test_ctx_member_sign_ext:FAIL:join_cgroup /ldsx_test unexpected
> join_cgroup /ldsx_test: actual -1 < expected 0
> #117/2 ldsx_insn/ctx_member_sign_ext:FAIL
> #117 ldsx_insn:FAIL
> Summary: 0/1 PASSED, 0 SKIPPED, 1 FAILED
>
>
> Huacai
>
> On Thu, Dec 7, 2023 at 1:53 PM Hengqi Chen <hengqi.chen@gmail.com> wrote:
> >
> > As reported on mailing list ([0]), several BPF testcases could
> > triggered kernel panics like:
> >
> > # ./test_progs -t cls_redirect
> > Can't find bpf_testmod.ko kernel module: -2
> > WARNING! Selftests relying on bpf_testmod.ko will be skipped.
> > [ 30.938489] CPU 3 Unable to handle kernel paging request at virtual address fffffffffd814de0, era == ffff800002009fb8, ra == ffff800002009f9c
> > [ 30.939331] Oops[#1]:
> > [ 30.939513] CPU: 3 PID: 1260 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
> > [ 30.939732] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
> > [ 30.939901] pc ffff800002009fb8 ra ffff800002009f9c tp 9000000104da4000 sp 9000000104da7ab0
> > [ 30.940038] a0 fffffffffd814de0 a1 9000000104da7a68 a2 0000000000000000 a3 9000000104da7c10
> > [ 30.940183] a4 9000000104da7c14 a5 0000000000000002 a6 0000000000000021 a7 00005555904d7f90
> > [ 30.940321] t0 0000000000000110 t1 0000000000000000 t2 fffffffffd814de0 t3 0004c4b400000000
> > [ 30.940456] t4 ffffffffffffffff t5 00000000c3f63600 t6 0000000000000000 t7 0000000000000000
> > [ 30.940590] t8 000000000006d803 u0 0000000000000020 s9 9000000104da7b10 s0 900000010504c200
> > [ 30.940727] s1 fffffffffd814de0 s2 900000010504c200 s3 9000000104da7c10 s4 9000000104da7ad0
> > [ 30.940866] s5 0000000000000000 s6 90000000030e65bc s7 9000000104da7b44 s8 90000000044f6fc0
> > [ 30.941015] ra: ffff800002009f9c bpf_prog_846803e5ae81417f_cls_redirect+0xa0/0x590
> > [ 30.941535] ERA: ffff800002009fb8 bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
> > [ 30.941696] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
> > [ 30.942224] PRMD: 00000004 (PPLV0 +PIE -PWE)
> > [ 30.942330] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
> > [ 30.942453] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
> > [ 30.942612] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
> > [ 30.942764] BADV: fffffffffd814de0
> > [ 30.942854] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
> > [ 30.942974] Modules linked in:
> > [ 30.943078] Process test_progs (pid: 1260, threadinfo=00000000ce303226, task=000000007d10bb76)
> > [ 30.943306] Stack : 900000010a064000 90000000044f6fc0 9000000104da7b48 0000000000000000
> > [ 30.943495] 0000000000000000 9000000104da7c14 9000000104da7c10 900000010504c200
> > [ 30.943626] 0000000000000001 ffff80001b88c000 9000000104da7b70 90000000030e6668
> > [ 30.943785] 0000000000000000 9000000104da7b58 ffff80001b88c048 9000000003d05000
> > [ 30.943936] 900000000303ac88 0000000000000000 0000000000000000 9000000104da7b70
> > [ 30.944091] 0000000000000000 0000000000000001 0000000731eeab00 0000000000000000
> > [ 30.944245] ffff80001b88c000 0000000000000000 0000000000000000 54b99959429f83b8
> > [ 30.944402] ffff80001b88c000 90000000044f6fc0 9000000101d70000 ffff80001b88c000
> > [ 30.944538] 000000000000005a 900000010504c200 900000010a064000 900000010a067000
> > [ 30.944697] 9000000104da7d88 0000000000000000 9000000003d05000 90000000030e794c
> > [ 30.944852] ...
> > [ 30.944924] Call Trace:
> > [ 30.945120] [<ffff800002009fb8>] bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
> > [ 30.945650] [<90000000030e6668>] bpf_test_run+0x1ec/0x2f8
> > [ 30.945958] [<90000000030e794c>] bpf_prog_test_run_skb+0x31c/0x684
> > [ 30.946065] [<90000000026d4f68>] __sys_bpf+0x678/0x2724
> > [ 30.946159] [<90000000026d7288>] sys_bpf+0x20/0x2c
> > [ 30.946253] [<90000000032dd224>] do_syscall+0x7c/0x94
> > [ 30.946343] [<9000000002541c5c>] handle_syscall+0xbc/0x158
> > [ 30.946492]
> > [ 30.946549] Code: 0015030e 5c0009c0 5001d000 <28c00304> 02c00484 29c00304 00150009 2a42d2e4 0280200d
> > [ 30.946793]
> > [ 30.946971] ---[ end trace 0000000000000000 ]---
> > [ 32.093225] Kernel panic - not syncing: Fatal exception in interrupt
> > [ 32.093526] Kernel relocated by 0x2320000
> > [ 32.093630] .text @ 0x9000000002520000
> > [ 32.093725] .data @ 0x9000000003400000
> > [ 32.093792] .bss @ 0x9000000004413200
> > [ 34.971998] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
> >
> > Tracking this down reveals two different code paths lead to
> > these panics.
> >
> > 1. Signed extend function return value
> >
> > Take the `cls_redirect` test as an example, when subprog mode
> > is enabled, we have:
> >
> > cls_redirect()
> > -> get_global_metrics() returns pcpu ptr 0xfffffefffc00b480
> >
> > The pointer is later signed-extended to 0xfffffffffc00b480 at
> > `BPF_JMP | BPF_EXIT`. During BPF prog run, this triggers unhandled
> > page fault and a kernel panic.
> >
> > The `verifier_map_ptr_mixing` test is another victim of this
> > signed-extension.
> >
> > BPF verifier ensures all BPF progs loaded run to completion, so
> > every BPF prog has at least one `exit` instruction. Why do most of
> > them survive this signed-extension? That's because most BPF prog
> > types (if not all) return small non-negative integers, like TC or XDP.
> > Some prog types (like tracing) even ignore the return value.
> > In the above cases, we use subprogs, and subprogs return pointer
> > values, so bad things happened.
> >
> > 2. Signed extend memory load operand
> >
> > The `cgrp_local_storage` test triggers panics when doing memory
> > load (see `cgrp_ls_tp_btf.c` for details):
> >
> > ptr = bpf_cgrp_storage_get(&map_a, task->cgroups->dfl_cgrp, 0,
> > BPF_LOCAL_STORAGE_GET_F_CREATE);
> >
> > The expression `task->cgroups->dfl_cgrp` involves two memory load.
> > Since the field offset fits in imm12 or imm14, we use ldd or ldptrd
> > to perform memory load. But the ldd and ldptrd instructions both
> > have the side effect that it will signed-extended the imm operand.
> > Finally, we got the wrong addresses and result in kernel panics.
> >
> > Let's get rid of those fatal signed-extension instrutions to fix
> > these issues.
> > - For the first case, don't sext on return values like other arches.
> > - For the second case, we fallback to use a generic ldxd instruction.
> >
> > [0]: https://lore.kernel.org/loongarch/CAEyhmHT6UOryPZi7eEfw01Y_CjAqxy8NM6eKkdvdojJqB9P7eQ@mail.gmail.com/
> >
> > Hengqi Chen (2):
> > LoongArch: BPF: Don't sign extend function return value
> > LoongArch: BPF: Don't sign extend memory load operand
> >
> > arch/loongarch/net/bpf_jit.c | 12 ++----------
> > 1 file changed, 2 insertions(+), 10 deletions(-)
> >
> > --
> > 2.34.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions
2023-12-07 14:49 ` Hengqi Chen
@ 2023-12-08 0:48 ` Huacai Chen
0 siblings, 0 replies; 6+ messages in thread
From: Huacai Chen @ 2023-12-08 0:48 UTC (permalink / raw)
To: Hengqi Chen; +Cc: loongarch, yangtiezhu, hejinyang
On Thu, Dec 7, 2023 at 10:49 PM Hengqi Chen <hengqi.chen@gmail.com> wrote:
>
> Hi, Huacai,
>
> On Thu, Dec 7, 2023 at 6:05 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >
> > Hi, Hengqi and Tiezhu,
> >
> > I applied both of your fixes, but ldsx_insn/ctx_member_sign_ext still
> > fails. However it passes in Hengqi's original commit message.
> >
> > ./test_progs -t ldsx_insn
> >
>
> Testing good on my side, no regression.
>
> > test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec
> > test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec
> > libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22
> > libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524
> > test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected
> > error: -524 (errno 524)
> > #117/1 ldsx_insn/map_val and probed_memory:FAIL
> > (cgroup_helpers.c:97: errno: Invalid argument) Enabling controller
> > cpu: /mnt/cgroup.subtree_control
> > #117 ldsx_insn: Failed to setup cgroup environment
> > test_ctx_member_sign_ext:FAIL:join_cgroup /ldsx_test unexpected
> > join_cgroup /ldsx_test: actual -1 < expected 0
>
> It seems like it's related to your cgroup setup.
OK, I will recheck my environment, and could you please investigate
why movsx only hangs in unprivileged mode (before Tiezhu's fix)?
Huacai
>
> > #117/2 ldsx_insn/ctx_member_sign_ext:FAIL
> > #117/3 ldsx_insn/ctx_member_narrow_sign_ext:OK
> > #117 ldsx_insn:FAIL
> >
> > All error logs:
> > test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec
> > test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec
> > libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22
> > libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524
> > test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected
> > error: -524 (errno 524)
> > #117/1 ldsx_insn/map_val and probed_memory:FAIL
> > (cgroup_helpers.c:97: errno: Invalid argument) Enabling controller
> > cpu: /mnt/cgroup.subtree_control
> > #117 ldsx_insn: Failed to setup cgroup environment
> > test_ctx_member_sign_ext:FAIL:join_cgroup /ldsx_test unexpected
> > join_cgroup /ldsx_test: actual -1 < expected 0
> > #117/2 ldsx_insn/ctx_member_sign_ext:FAIL
> > #117 ldsx_insn:FAIL
> > Summary: 0/1 PASSED, 0 SKIPPED, 1 FAILED
> >
> >
> > Huacai
> >
> > On Thu, Dec 7, 2023 at 1:53 PM Hengqi Chen <hengqi.chen@gmail.com> wrote:
> > >
> > > As reported on mailing list ([0]), several BPF testcases could
> > > triggered kernel panics like:
> > >
> > > # ./test_progs -t cls_redirect
> > > Can't find bpf_testmod.ko kernel module: -2
> > > WARNING! Selftests relying on bpf_testmod.ko will be skipped.
> > > [ 30.938489] CPU 3 Unable to handle kernel paging request at virtual address fffffffffd814de0, era == ffff800002009fb8, ra == ffff800002009f9c
> > > [ 30.939331] Oops[#1]:
> > > [ 30.939513] CPU: 3 PID: 1260 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
> > > [ 30.939732] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
> > > [ 30.939901] pc ffff800002009fb8 ra ffff800002009f9c tp 9000000104da4000 sp 9000000104da7ab0
> > > [ 30.940038] a0 fffffffffd814de0 a1 9000000104da7a68 a2 0000000000000000 a3 9000000104da7c10
> > > [ 30.940183] a4 9000000104da7c14 a5 0000000000000002 a6 0000000000000021 a7 00005555904d7f90
> > > [ 30.940321] t0 0000000000000110 t1 0000000000000000 t2 fffffffffd814de0 t3 0004c4b400000000
> > > [ 30.940456] t4 ffffffffffffffff t5 00000000c3f63600 t6 0000000000000000 t7 0000000000000000
> > > [ 30.940590] t8 000000000006d803 u0 0000000000000020 s9 9000000104da7b10 s0 900000010504c200
> > > [ 30.940727] s1 fffffffffd814de0 s2 900000010504c200 s3 9000000104da7c10 s4 9000000104da7ad0
> > > [ 30.940866] s5 0000000000000000 s6 90000000030e65bc s7 9000000104da7b44 s8 90000000044f6fc0
> > > [ 30.941015] ra: ffff800002009f9c bpf_prog_846803e5ae81417f_cls_redirect+0xa0/0x590
> > > [ 30.941535] ERA: ffff800002009fb8 bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
> > > [ 30.941696] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
> > > [ 30.942224] PRMD: 00000004 (PPLV0 +PIE -PWE)
> > > [ 30.942330] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
> > > [ 30.942453] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
> > > [ 30.942612] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
> > > [ 30.942764] BADV: fffffffffd814de0
> > > [ 30.942854] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
> > > [ 30.942974] Modules linked in:
> > > [ 30.943078] Process test_progs (pid: 1260, threadinfo=00000000ce303226, task=000000007d10bb76)
> > > [ 30.943306] Stack : 900000010a064000 90000000044f6fc0 9000000104da7b48 0000000000000000
> > > [ 30.943495] 0000000000000000 9000000104da7c14 9000000104da7c10 900000010504c200
> > > [ 30.943626] 0000000000000001 ffff80001b88c000 9000000104da7b70 90000000030e6668
> > > [ 30.943785] 0000000000000000 9000000104da7b58 ffff80001b88c048 9000000003d05000
> > > [ 30.943936] 900000000303ac88 0000000000000000 0000000000000000 9000000104da7b70
> > > [ 30.944091] 0000000000000000 0000000000000001 0000000731eeab00 0000000000000000
> > > [ 30.944245] ffff80001b88c000 0000000000000000 0000000000000000 54b99959429f83b8
> > > [ 30.944402] ffff80001b88c000 90000000044f6fc0 9000000101d70000 ffff80001b88c000
> > > [ 30.944538] 000000000000005a 900000010504c200 900000010a064000 900000010a067000
> > > [ 30.944697] 9000000104da7d88 0000000000000000 9000000003d05000 90000000030e794c
> > > [ 30.944852] ...
> > > [ 30.944924] Call Trace:
> > > [ 30.945120] [<ffff800002009fb8>] bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
> > > [ 30.945650] [<90000000030e6668>] bpf_test_run+0x1ec/0x2f8
> > > [ 30.945958] [<90000000030e794c>] bpf_prog_test_run_skb+0x31c/0x684
> > > [ 30.946065] [<90000000026d4f68>] __sys_bpf+0x678/0x2724
> > > [ 30.946159] [<90000000026d7288>] sys_bpf+0x20/0x2c
> > > [ 30.946253] [<90000000032dd224>] do_syscall+0x7c/0x94
> > > [ 30.946343] [<9000000002541c5c>] handle_syscall+0xbc/0x158
> > > [ 30.946492]
> > > [ 30.946549] Code: 0015030e 5c0009c0 5001d000 <28c00304> 02c00484 29c00304 00150009 2a42d2e4 0280200d
> > > [ 30.946793]
> > > [ 30.946971] ---[ end trace 0000000000000000 ]---
> > > [ 32.093225] Kernel panic - not syncing: Fatal exception in interrupt
> > > [ 32.093526] Kernel relocated by 0x2320000
> > > [ 32.093630] .text @ 0x9000000002520000
> > > [ 32.093725] .data @ 0x9000000003400000
> > > [ 32.093792] .bss @ 0x9000000004413200
> > > [ 34.971998] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
> > >
> > > Tracking this down reveals two different code paths lead to
> > > these panics.
> > >
> > > 1. Signed extend function return value
> > >
> > > Take the `cls_redirect` test as an example, when subprog mode
> > > is enabled, we have:
> > >
> > > cls_redirect()
> > > -> get_global_metrics() returns pcpu ptr 0xfffffefffc00b480
> > >
> > > The pointer is later signed-extended to 0xfffffffffc00b480 at
> > > `BPF_JMP | BPF_EXIT`. During BPF prog run, this triggers unhandled
> > > page fault and a kernel panic.
> > >
> > > The `verifier_map_ptr_mixing` test is another victim of this
> > > signed-extension.
> > >
> > > BPF verifier ensures all BPF progs loaded run to completion, so
> > > every BPF prog has at least one `exit` instruction. Why do most of
> > > them survive this signed-extension? That's because most BPF prog
> > > types (if not all) return small non-negative integers, like TC or XDP.
> > > Some prog types (like tracing) even ignore the return value.
> > > In the above cases, we use subprogs, and subprogs return pointer
> > > values, so bad things happened.
> > >
> > > 2. Signed extend memory load operand
> > >
> > > The `cgrp_local_storage` test triggers panics when doing memory
> > > load (see `cgrp_ls_tp_btf.c` for details):
> > >
> > > ptr = bpf_cgrp_storage_get(&map_a, task->cgroups->dfl_cgrp, 0,
> > > BPF_LOCAL_STORAGE_GET_F_CREATE);
> > >
> > > The expression `task->cgroups->dfl_cgrp` involves two memory load.
> > > Since the field offset fits in imm12 or imm14, we use ldd or ldptrd
> > > to perform memory load. But the ldd and ldptrd instructions both
> > > have the side effect that it will signed-extended the imm operand.
> > > Finally, we got the wrong addresses and result in kernel panics.
> > >
> > > Let's get rid of those fatal signed-extension instrutions to fix
> > > these issues.
> > > - For the first case, don't sext on return values like other arches.
> > > - For the second case, we fallback to use a generic ldxd instruction.
> > >
> > > [0]: https://lore.kernel.org/loongarch/CAEyhmHT6UOryPZi7eEfw01Y_CjAqxy8NM6eKkdvdojJqB9P7eQ@mail.gmail.com/
> > >
> > > Hengqi Chen (2):
> > > LoongArch: BPF: Don't sign extend function return value
> > > LoongArch: BPF: Don't sign extend memory load operand
> > >
> > > arch/loongarch/net/bpf_jit.c | 12 ++----------
> > > 1 file changed, 2 insertions(+), 10 deletions(-)
> > >
> > > --
> > > 2.34.1
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-12-08 0:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-12-06 7:38 [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Hengqi Chen
2023-12-06 7:38 ` [PATCH 1/2] LoongArch: BPF: Don't sign extend function return value Hengqi Chen
2023-12-06 7:38 ` [PATCH 2/2] LoongArch: BPF: Don't sign extend memory load operand Hengqi Chen
2023-12-07 10:05 ` [PATCH 0/2] LoongArch: BPF: Remove fatal signed-extension instructions Huacai Chen
2023-12-07 14:49 ` Hengqi Chen
2023-12-08 0:48 ` Huacai Chen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox