bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues
@ 2025-08-27  9:47 Hengqi Chen
  2025-08-27  9:47 ` [PATCH v2 1/3] LoongArch: BPF: Remove duplicated flags check Hengqi Chen
                   ` (3 more replies)
  0 siblings, 4 replies; 10+ messages in thread
From: Hengqi Chen @ 2025-08-27  9:47 UTC (permalink / raw)
  To: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, vincent.mc.li
  Cc: bpf, loongarch, Hengqi Chen

The following two selftest cases triggers oops on LoongArch:

    $ ./test_progs -a ns_bpf_qdisc -a tracing_struct

This small series tries to fix/workaround these issues.
See individual commit for details.

While at it, remove a duplicated flags check in __arch_prepare_bpf_trampoline().

v1 -> v2:
* collect Acked-by/Tested-by tags
* update sign_extend() in patch 2 as suggested by Huacai

Hengqi Chen (3):
  LoongArch: BPF: Remove duplicated flags check
  LoongArch: BPF: Sign extend struct ops return values properly
  LoongArch: BPF: No support of struct argument in trampoline programs

 arch/loongarch/net/bpf_jit.c | 35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

--
2.43.5

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH v2 1/3] LoongArch: BPF: Remove duplicated flags check
  2025-08-27  9:47 [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Hengqi Chen
@ 2025-08-27  9:47 ` Hengqi Chen
  2025-08-27  9:47 ` [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly Hengqi Chen
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 10+ messages in thread
From: Hengqi Chen @ 2025-08-27  9:47 UTC (permalink / raw)
  To: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, vincent.mc.li
  Cc: bpf, loongarch, Hengqi Chen

The check for (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY)
is duplicated in __arch_prepare_bpf_trampoline(). Remove it.

Acked-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
---
 arch/loongarch/net/bpf_jit.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
index abfdb6bb5c38..b646c6b73014 100644
--- a/arch/loongarch/net/bpf_jit.c
+++ b/arch/loongarch/net/bpf_jit.c
@@ -1462,9 +1462,6 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
 	struct bpf_tramp_links *fmod_ret = &tlinks[BPF_TRAMP_MODIFY_RETURN];
 	u32 **branches = NULL;
 
-	if (flags & (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY))
-		return -ENOTSUPP;
-
 	/*
 	 * FP + 8       [ RA to parent func ] return address to parent
 	 *                    function
-- 
2.43.5



^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly
  2025-08-27  9:47 [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Hengqi Chen
  2025-08-27  9:47 ` [PATCH v2 1/3] LoongArch: BPF: Remove duplicated flags check Hengqi Chen
@ 2025-08-27  9:47 ` Hengqi Chen
  2025-08-28  6:11   ` Jinyang He
  2025-08-27  9:47 ` [PATCH v2 3/3] LoongArch: BPF: No support of struct argument in trampoline programs Hengqi Chen
  2025-08-27 14:22 ` [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Vincent Li
  3 siblings, 1 reply; 10+ messages in thread
From: Hengqi Chen @ 2025-08-27  9:47 UTC (permalink / raw)
  To: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, vincent.mc.li
  Cc: bpf, loongarch, Hengqi Chen

The ns_bpf_qdisc selftest triggers a kernel panic:

    CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4
    Oops[#1]:
    CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G           OE       6.16.0+ #3 PREEMPT(full)
    Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
    Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
    pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600
    a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008
    a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000
    t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001
    t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d
    t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800
    s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880
    s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000
       ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8
      ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8
     CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
     PRMD: 00000004 (PPLV0 +PIE -PWE)
     EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
     ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
    ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
     BADV: 0000000000741d58
     PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
    Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]
    Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)
    Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8
            90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000
            900000010597c400 900000008694a000 0000000000000000 9000000105b59000
            90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c
            9000000086936000 0000000100094d4c fffffff400676208 0000000000000000
            9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000
            9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000
            9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840
            0000000000000000 9000000086be6c40 0000000000000000 0000000000000000
            0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4
            ...
    Call Trace:
    [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8
    [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0
    [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950
    [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448
    [<9000000085370b24>] ip6_xmit+0x304/0x858
    [<90000000853c4438>] inet6_csk_xmit+0x100/0x170
    [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0
    [<90000000852b47fc>] tcp_connect+0xbcc/0x1168
    [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0
    [<90000000852e7738>] __inet_stream_connect+0x170/0x480
    [<90000000852e7a98>] inet_stream_connect+0x50/0x88
    [<90000000850f2814>] __sys_connect+0xe4/0x110
    [<90000000850f2858>] sys_connect+0x18/0x28
    [<9000000085520c94>] do_syscall+0x94/0x1a0
    [<9000000083df1fb8>] handle_syscall+0xb8/0x158

    Code: 4001ad80  2400873f  2400832d <240073cc> 001137ff  001133ff  6407b41f  001503cc  0280041d

    ---[ end trace 0000000000000000 ]---

The bpf_fifo_dequeue prog returns a skb which is a pointer.
The pointer is treated as a 32bit value and sign extend to
64bit in epilogue. This behavior is right for most bpf prog
types but wrong for struct ops which requires LoongArch ABI.

So let's sign extend struct ops return values according to
the return value spec in function model.

Fixes: 6abf17d690d8 ("LoongArch: BPF: Add struct ops support for trampoline")
Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
---
 arch/loongarch/net/bpf_jit.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
index b646c6b73014..c239e5ed0c92 100644
--- a/arch/loongarch/net/bpf_jit.c
+++ b/arch/loongarch/net/bpf_jit.c
@@ -1448,6 +1448,28 @@ void arch_free_bpf_trampoline(void *image, unsigned int size)
 	bpf_prog_pack_free(image, size);
 }
 
+/*
+ * Sign-extend the register if necessary
+ */
+static void sign_extend(struct jit_ctx *ctx, int r, u8 size)
+{
+	switch (size) {
+	case 1:
+		emit_insn(ctx, extwb, r, r);
+		break;
+	case 2:
+		emit_insn(ctx, extwh, r, r);
+		break;
+	case 4:
+		emit_insn(ctx, addiw, r, r, 0);
+		break;
+	case 8:
+		break;
+	default:
+		pr_warn("bpf_jit: invalid size %d for sign_extend\n", size);
+	}
+}
+
 static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
 					 const struct btf_func_model *m, struct bpf_tramp_links *tlinks,
 					 void *func_addr, u32 flags)
@@ -1654,6 +1676,10 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
 	if (save_ret) {
 		emit_insn(ctx, ldd, LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -retval_off);
 		emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP, -(retval_off - 8));
+		if (is_struct_ops) {
+			move_reg(ctx, LOONGARCH_GPR_A0, regmap[BPF_REG_0]);
+			sign_extend(ctx, LOONGARCH_GPR_A0, m->ret_size);
+		}
 	}
 
 	emit_insn(ctx, ldd, LOONGARCH_GPR_S1, LOONGARCH_GPR_FP, -sreg_off);
-- 
2.43.5



^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH v2 3/3] LoongArch: BPF: No support of struct argument in trampoline programs
  2025-08-27  9:47 [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Hengqi Chen
  2025-08-27  9:47 ` [PATCH v2 1/3] LoongArch: BPF: Remove duplicated flags check Hengqi Chen
  2025-08-27  9:47 ` [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly Hengqi Chen
@ 2025-08-27  9:47 ` Hengqi Chen
  2025-08-28  9:26   ` Huacai Chen
  2025-08-27 14:22 ` [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Vincent Li
  3 siblings, 1 reply; 10+ messages in thread
From: Hengqi Chen @ 2025-08-27  9:47 UTC (permalink / raw)
  To: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, vincent.mc.li
  Cc: bpf, loongarch, Hengqi Chen

The current implementation does not support struct argument.
This cause a oops when running bpf selftest:

    $ ./test_progs -a tracing_struct
    CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 90000000845659f4, ra == 90000000845659e8
    Oops[#1]:
    CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938
    rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
    rcu:     1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801
    rcu:     (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)
    Sending NMI from CPU 0 to CPUs 1:
    rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2
    rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
    rcu: RCU grace-period kthread stack dump:
    task:rcu_preempt     state:I stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000800
    Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680
            9000000085d88000 0000000000000000 0000000000000040 9000000087159350
            9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005
            00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004
            9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e
            00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350
            900000008715bf98 0000000000000005 9000000087036000 900000008704a000
            9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0
            00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000
            9000000007002150 00000000ffff355b 9000000084615480 0000000007000002
            ...
    Call Trace:
    [<9000000085c2a868>] __schedule+0x410/0x1520
    [<9000000085c2b9ac>] schedule+0x34/0x190
    [<9000000085c33d38>] schedule_timeout+0x98/0x140
    [<90000000845e9120>] rcu_gp_fqs_loop+0x5f8/0x868
    [<90000000845ed538>] rcu_gp_kthread+0x260/0x2e0
    [<900000008454e8a4>] kthread+0x144/0x238
    [<9000000085c26b60>] ret_from_kernel_thread+0x28/0xc8
    [<90000000844f20e4>] ret_from_kernel_thread_asm+0xc/0x88

    rcu: Stack dump where RCU GP kthread last ran:
    Sending NMI from CPU 0 to CPUs 2:
    NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4

Reject it for now.

Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support")
Acked-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tested-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
---
 arch/loongarch/net/bpf_jit.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
index c239e5ed0c92..66b102ed9874 100644
--- a/arch/loongarch/net/bpf_jit.c
+++ b/arch/loongarch/net/bpf_jit.c
@@ -1514,6 +1514,12 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
 	if (m->nr_args > LOONGARCH_MAX_REG_ARGS)
 		return -ENOTSUPP;
 
+	/* don't support struct argument */
+	for (i = 0; i < m->nr_args; i++) {
+		if (m->arg_flags[i] & BTF_FMODEL_STRUCT_ARG)
+			return -ENOTSUPP;
+	}
+
 	if (flags & (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY))
 		return -ENOTSUPP;
 
-- 
2.43.5



^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues
  2025-08-27  9:47 [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Hengqi Chen
                   ` (2 preceding siblings ...)
  2025-08-27  9:47 ` [PATCH v2 3/3] LoongArch: BPF: No support of struct argument in trampoline programs Hengqi Chen
@ 2025-08-27 14:22 ` Vincent Li
  3 siblings, 0 replies; 10+ messages in thread
From: Vincent Li @ 2025-08-27 14:22 UTC (permalink / raw)
  To: Hengqi Chen
  Cc: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, bpf, loongarch

On Wed, Aug 27, 2025 at 4:19 AM Hengqi Chen <hengqi.chen@gmail.com> wrote:
>
> The following two selftest cases triggers oops on LoongArch:
>
>     $ ./test_progs -a ns_bpf_qdisc -a tracing_struct

Last time I skipped struct_ops test and now I updated the test
accordingly, no kernel hangs and test result is expected for this
series:

./test_progs \
--deny=module_attach \
--deny=subprogs_extable \
--deny=timer_lockup \
--json-summary="./bpf_selftests.json"

#213/1   ns_bpf_qdisc/fifo:OK
#213/2   ns_bpf_qdisc/fq:OK
#213/3   ns_bpf_qdisc/attach to mq:OK
#213/4   ns_bpf_qdisc/attach to non root:OK
#213/5   ns_bpf_qdisc/incompl_ops:OK
#213     ns_bpf_qdisc:OK

#408/1   struct_ops_autocreate/cant_load_full_object:OK
#408/2   struct_ops_autocreate/can_load_partial_object:OK
#408/3   struct_ops_autocreate/autoload_and_shadow_vars:OK
#408/4   struct_ops_autocreate/optional_maps:OK
#408     struct_ops_autocreate:OK
#409/1   struct_ops_kptr_return/kptr_return:OK
#409/2   struct_ops_kptr_return/kptr_return_fail__wrong_type:OK
#409/3   struct_ops_kptr_return/kptr_return_fail__invalid_scalar:OK
#409/4   struct_ops_kptr_return/kptr_return_fail__nonzero_offset:OK
#409/5   struct_ops_kptr_return/kptr_return_fail__local_kptr:OK
#409     struct_ops_kptr_return:OK
#410/1   struct_ops_maybe_null/maybe_null:OK
#410/2   struct_ops_maybe_null/maybe_null_fail:OK
#410     struct_ops_maybe_null:OK
#411/1   struct_ops_module/struct_ops_load:OK
#411/2   struct_ops_module/struct_ops_not_zeroed:OK
#411/3   struct_ops_module/struct_ops_incompatible:OK
#411/4   struct_ops_module/struct_ops_null_out_cb:OK
#411/5   struct_ops_module/struct_ops_forgotten_cb:OK
#411/6   struct_ops_module/test_detach_link:OK
#411/7   struct_ops_module/unsupported_ops:OK
#411     struct_ops_module:OK
do_struct_ops_multi_pages:PASS:struct_ops_multi_pages_open_and_load 0 nsec
do_struct_ops_multi_pages:FAIL:attach_multi_pages unexpected error: -7
#412/1   struct_ops_multi_pages/multi_pages:FAIL
#412     struct_ops_multi_pages:FAIL
#413/1   struct_ops_no_cfi/load_bpf_test_no_cfi:OK
#413     struct_ops_no_cfi:OK
#414/1   struct_ops_private_stack/private_stack:SKIP
#414/2   struct_ops_private_stack/private_stack_fail:SKIP
#414/3   struct_ops_private_stack/private_stack_recur:SKIP
#414     struct_ops_private_stack:SKIP
#415/1   struct_ops_refcounted/refcounted:OK
#415/2   struct_ops_refcounted/refcounted_fail__ref_leak:OK
#415/3   struct_ops_refcounted/refcounted_fail__global_subprog:OK
#415/4   struct_ops_refcounted/refcounted_fail__tail_call:OK
#415     struct_ops_refcounted:OK

test_struct_args:PASS:tracing_struct__open_and_load 0 nsec
libbpf: prog 'test_struct_arg_1': failed to attach: -ENOTSUPP
libbpf: prog 'test_struct_arg_1': failed to auto-attach: -ENOTSUPP
test_struct_args:FAIL:tracing_struct__attach unexpected error: -524 (errno 524)
#468/1   tracing_struct/struct_args:FAIL
test_struct_many_args:PASS:tracing_struct_many_args__open_and_load 0 nsec
libbpf: prog 'test_struct_many_args_1': failed to attach: -ENOTSUPP
libbpf: prog 'test_struct_many_args_1': failed to auto-attach: -ENOTSUPP
test_struct_many_args:FAIL:tracing_struct_many_args__attach unexpected
error: -524 (errno 524)

>
> This small series tries to fix/workaround these issues.
> See individual commit for details.
>
> While at it, remove a duplicated flags check in __arch_prepare_bpf_trampoline().
>
> v1 -> v2:
> * collect Acked-by/Tested-by tags
> * update sign_extend() in patch 2 as suggested by Huacai
>
> Hengqi Chen (3):
>   LoongArch: BPF: Remove duplicated flags check
>   LoongArch: BPF: Sign extend struct ops return values properly
>   LoongArch: BPF: No support of struct argument in trampoline programs
>
>  arch/loongarch/net/bpf_jit.c | 35 ++++++++++++++++++++++++++++++++---
>  1 file changed, 32 insertions(+), 3 deletions(-)
>
> --
> 2.43.5

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly
  2025-08-27  9:47 ` [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly Hengqi Chen
@ 2025-08-28  6:11   ` Jinyang He
  2025-08-28  9:24     ` Hengqi Chen
  0 siblings, 1 reply; 10+ messages in thread
From: Jinyang He @ 2025-08-28  6:11 UTC (permalink / raw)
  To: Hengqi Chen
  Cc: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, vincent.mc.li, bpf, loongarch

On 2025-08-27 17:47, Hengqi Chen wrote:

> The ns_bpf_qdisc selftest triggers a kernel panic:
>
>      CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4
>      Oops[#1]:
>      CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G           OE       6.16.0+ #3 PREEMPT(full)
>      Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>      Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
>      pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600
>      a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008
>      a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000
>      t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001
>      t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d
>      t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800
>      s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880
>      s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000
>         ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8
>        ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8
>       CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
>       PRMD: 00000004 (PPLV0 +PIE -PWE)
>       EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
>       ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
>      ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
>       BADV: 0000000000741d58
>       PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
>      Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]
>      Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)
>      Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8
>              90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000
>              900000010597c400 900000008694a000 0000000000000000 9000000105b59000
>              90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c
>              9000000086936000 0000000100094d4c fffffff400676208 0000000000000000
>              9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000
>              9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000
>              9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840
>              0000000000000000 9000000086be6c40 0000000000000000 0000000000000000
>              0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4
>              ...
>      Call Trace:
>      [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8
>      [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0
>      [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950
>      [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448
>      [<9000000085370b24>] ip6_xmit+0x304/0x858
>      [<90000000853c4438>] inet6_csk_xmit+0x100/0x170
>      [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0
>      [<90000000852b47fc>] tcp_connect+0xbcc/0x1168
>      [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0
>      [<90000000852e7738>] __inet_stream_connect+0x170/0x480
>      [<90000000852e7a98>] inet_stream_connect+0x50/0x88
>      [<90000000850f2814>] __sys_connect+0xe4/0x110
>      [<90000000850f2858>] sys_connect+0x18/0x28
>      [<9000000085520c94>] do_syscall+0x94/0x1a0
>      [<9000000083df1fb8>] handle_syscall+0xb8/0x158
>
>      Code: 4001ad80  2400873f  2400832d <240073cc> 001137ff  001133ff  6407b41f  001503cc  0280041d
>
>      ---[ end trace 0000000000000000 ]---
>
> The bpf_fifo_dequeue prog returns a skb which is a pointer.
> The pointer is treated as a 32bit value and sign extend to
> 64bit in epilogue. This behavior is right for most bpf prog
> types but wrong for struct ops which requires LoongArch ABI.
>
> So let's sign extend struct ops return values according to
> the return value spec in function model.
>
> Fixes: 6abf17d690d8 ("LoongArch: BPF: Add struct ops support for trampoline")
> Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> Tested-by: Vincent Li <vincent.mc.li@gmail.com>
> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
> ---
>   arch/loongarch/net/bpf_jit.c | 26 ++++++++++++++++++++++++++
>   1 file changed, 26 insertions(+)
>
> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> index b646c6b73014..c239e5ed0c92 100644
> --- a/arch/loongarch/net/bpf_jit.c
> +++ b/arch/loongarch/net/bpf_jit.c
> @@ -1448,6 +1448,28 @@ void arch_free_bpf_trampoline(void *image, unsigned int size)
>   	bpf_prog_pack_free(image, size);
>   }
>   
> +/*
> + * Sign-extend the register if necessary
> + */
> +static void sign_extend(struct jit_ctx *ctx, int r, u8 size)
> +{
> +	switch (size) {
> +	case 1:
> +		emit_insn(ctx, extwb, r, r);
> +		break;
> +	case 2:
> +		emit_insn(ctx, extwh, r, r);
> +		break;
> +	case 4:
> +		emit_insn(ctx, addiw, r, r, 0);
> +		break;
> +	case 8:
> +		break;
> +	default:
> +		pr_warn("bpf_jit: invalid size %d for sign_extend\n", size);
> +	}
> +}
> +
>   static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
>   					 const struct btf_func_model *m, struct bpf_tramp_links *tlinks,
>   					 void *func_addr, u32 flags)
> @@ -1654,6 +1676,10 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
>   	if (save_ret) {
>   		emit_insn(ctx, ldd, LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -retval_off);
>   		emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP, -(retval_off - 8));
> +		if (is_struct_ops) {
> +			move_reg(ctx, LOONGARCH_GPR_A0, regmap[BPF_REG_0]);
> +			sign_extend(ctx, LOONGARCH_GPR_A0, m->ret_size);
> +		}
>   	}
Hi, Hengqi,

It can be did same as Tiezhu's patch, named "LoongArch: BPF: Optimize
sign-extention mov instructions", which use only one sign-extend 
instruction.

And btw, how about,
if (save_ret) {
   if (is_struct_ops) {
     ld.{d,w,h,b} LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -(retval_off - 8)
     emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP, 
-(retval_off - 8)); // I don't know is it needed.
   } else {
     emit_insn(ctx, ldd, LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -retval_off);
     emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP, 
-(retval_off - 8));
   }
}
>   
>   	emit_insn(ctx, ldd, LOONGARCH_GPR_S1, LOONGARCH_GPR_FP, -sreg_off);


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly
  2025-08-28  6:11   ` Jinyang He
@ 2025-08-28  9:24     ` Hengqi Chen
  2025-08-28 10:40       ` Jinyang He
  0 siblings, 1 reply; 10+ messages in thread
From: Hengqi Chen @ 2025-08-28  9:24 UTC (permalink / raw)
  To: Jinyang He
  Cc: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, vincent.mc.li, bpf, loongarch

On Thu, Aug 28, 2025 at 2:11 PM Jinyang He <hejinyang@loongson.cn> wrote:
>
> On 2025-08-27 17:47, Hengqi Chen wrote:
>
> > The ns_bpf_qdisc selftest triggers a kernel panic:
> >
> >      CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4
> >      Oops[#1]:
> >      CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G           OE       6.16.0+ #3 PREEMPT(full)
> >      Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> >      Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
> >      pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600
> >      a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008
> >      a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000
> >      t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001
> >      t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d
> >      t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800
> >      s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880
> >      s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000
> >         ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8
> >        ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8
> >       CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
> >       PRMD: 00000004 (PPLV0 +PIE -PWE)
> >       EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
> >       ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
> >      ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
> >       BADV: 0000000000741d58
> >       PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
> >      Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]
> >      Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)
> >      Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8
> >              90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000
> >              900000010597c400 900000008694a000 0000000000000000 9000000105b59000
> >              90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c
> >              9000000086936000 0000000100094d4c fffffff400676208 0000000000000000
> >              9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000
> >              9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000
> >              9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840
> >              0000000000000000 9000000086be6c40 0000000000000000 0000000000000000
> >              0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4
> >              ...
> >      Call Trace:
> >      [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8
> >      [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0
> >      [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950
> >      [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448
> >      [<9000000085370b24>] ip6_xmit+0x304/0x858
> >      [<90000000853c4438>] inet6_csk_xmit+0x100/0x170
> >      [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0
> >      [<90000000852b47fc>] tcp_connect+0xbcc/0x1168
> >      [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0
> >      [<90000000852e7738>] __inet_stream_connect+0x170/0x480
> >      [<90000000852e7a98>] inet_stream_connect+0x50/0x88
> >      [<90000000850f2814>] __sys_connect+0xe4/0x110
> >      [<90000000850f2858>] sys_connect+0x18/0x28
> >      [<9000000085520c94>] do_syscall+0x94/0x1a0
> >      [<9000000083df1fb8>] handle_syscall+0xb8/0x158
> >
> >      Code: 4001ad80  2400873f  2400832d <240073cc> 001137ff  001133ff  6407b41f  001503cc  0280041d
> >
> >      ---[ end trace 0000000000000000 ]---
> >
> > The bpf_fifo_dequeue prog returns a skb which is a pointer.
> > The pointer is treated as a 32bit value and sign extend to
> > 64bit in epilogue. This behavior is right for most bpf prog
> > types but wrong for struct ops which requires LoongArch ABI.
> >
> > So let's sign extend struct ops return values according to
> > the return value spec in function model.
> >
> > Fixes: 6abf17d690d8 ("LoongArch: BPF: Add struct ops support for trampoline")
> > Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> > Tested-by: Vincent Li <vincent.mc.li@gmail.com>
> > Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
> > ---
> >   arch/loongarch/net/bpf_jit.c | 26 ++++++++++++++++++++++++++
> >   1 file changed, 26 insertions(+)
> >
> > diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> > index b646c6b73014..c239e5ed0c92 100644
> > --- a/arch/loongarch/net/bpf_jit.c
> > +++ b/arch/loongarch/net/bpf_jit.c
> > @@ -1448,6 +1448,28 @@ void arch_free_bpf_trampoline(void *image, unsigned int size)
> >       bpf_prog_pack_free(image, size);
> >   }
> >
> > +/*
> > + * Sign-extend the register if necessary
> > + */
> > +static void sign_extend(struct jit_ctx *ctx, int r, u8 size)
> > +{
> > +     switch (size) {
> > +     case 1:
> > +             emit_insn(ctx, extwb, r, r);
> > +             break;
> > +     case 2:
> > +             emit_insn(ctx, extwh, r, r);
> > +             break;
> > +     case 4:
> > +             emit_insn(ctx, addiw, r, r, 0);
> > +             break;
> > +     case 8:
> > +             break;
> > +     default:
> > +             pr_warn("bpf_jit: invalid size %d for sign_extend\n", size);
> > +     }
> > +}
> > +
> >   static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
> >                                        const struct btf_func_model *m, struct bpf_tramp_links *tlinks,
> >                                        void *func_addr, u32 flags)
> > @@ -1654,6 +1676,10 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
> >       if (save_ret) {
> >               emit_insn(ctx, ldd, LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -retval_off);
> >               emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP, -(retval_off - 8));
> > +             if (is_struct_ops) {
> > +                     move_reg(ctx, LOONGARCH_GPR_A0, regmap[BPF_REG_0]);
> > +                     sign_extend(ctx, LOONGARCH_GPR_A0, m->ret_size);
> > +             }
> >       }
> Hi, Hengqi,
>
> It can be did same as Tiezhu's patch, named "LoongArch: BPF: Optimize
> sign-extention mov instructions", which use only one sign-extend
> instruction.
>
> And btw, how about,
> if (save_ret) {
>    if (is_struct_ops) {
>      ld.{d,w,h,b} LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -(retval_off - 8)
>      emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP,
> -(retval_off - 8)); // I don't know is it needed.
>    } else {
>      emit_insn(ctx, ldd, LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -retval_off);
>      emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP,
> -(retval_off - 8));
>    }

Hmm, how about:

static void sign_extend(struct jit_ctx *ctx, int rd, int rj, u8 size)

and sign extend regmap[BPF_REG_0] to LOONGARCH_GPR_A0

> }
> >
> >       emit_insn(ctx, ldd, LOONGARCH_GPR_S1, LOONGARCH_GPR_FP, -sreg_off);
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 3/3] LoongArch: BPF: No support of struct argument in trampoline programs
  2025-08-27  9:47 ` [PATCH v2 3/3] LoongArch: BPF: No support of struct argument in trampoline programs Hengqi Chen
@ 2025-08-28  9:26   ` Huacai Chen
  2025-08-28 11:03     ` Hengqi Chen
  0 siblings, 1 reply; 10+ messages in thread
From: Huacai Chen @ 2025-08-28  9:26 UTC (permalink / raw)
  To: Hengqi Chen
  Cc: yangtiezhu, jianghaoran, duanchenghao, ast, daniel, andrii,
	martin.lau, vincent.mc.li, bpf, loongarch

On Wed, Aug 27, 2025 at 7:19 PM Hengqi Chen <hengqi.chen@gmail.com> wrote:
>
> The current implementation does not support struct argument.
> This cause a oops when running bpf selftest:
>
>     $ ./test_progs -a tracing_struct
>     CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 90000000845659f4, ra == 90000000845659e8
>     Oops[#1]:
>     CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938
>     rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
>     rcu:     1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801
>     rcu:     (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)
>     Sending NMI from CPU 0 to CPUs 1:
>     rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2
>     rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
>     rcu: RCU grace-period kthread stack dump:
>     task:rcu_preempt     state:I stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000800
>     Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680
>             9000000085d88000 0000000000000000 0000000000000040 9000000087159350
>             9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005
>             00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004
>             9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e
>             00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350
>             900000008715bf98 0000000000000005 9000000087036000 900000008704a000
>             9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0
>             00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000
>             9000000007002150 00000000ffff355b 9000000084615480 0000000007000002
>             ...
>     Call Trace:
>     [<9000000085c2a868>] __schedule+0x410/0x1520
>     [<9000000085c2b9ac>] schedule+0x34/0x190
>     [<9000000085c33d38>] schedule_timeout+0x98/0x140
>     [<90000000845e9120>] rcu_gp_fqs_loop+0x5f8/0x868
>     [<90000000845ed538>] rcu_gp_kthread+0x260/0x2e0
>     [<900000008454e8a4>] kthread+0x144/0x238
>     [<9000000085c26b60>] ret_from_kernel_thread+0x28/0xc8
>     [<90000000844f20e4>] ret_from_kernel_thread_asm+0xc/0x88
>
>     rcu: Stack dump where RCU GP kthread last ran:
>     Sending NMI from CPU 0 to CPUs 2:
>     NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4
>
> Reject it for now.
Drop this patch or pick Tiezhu's patches as a single series?
https://lore.kernel.org/loongarch/20250821144302.14010-1-yangtiezhu@loongson.cn/T/#t

Huacai

>
> Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support")
> Acked-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> Tested-by: Vincent Li <vincent.mc.li@gmail.com>
> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
> ---
>  arch/loongarch/net/bpf_jit.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> index c239e5ed0c92..66b102ed9874 100644
> --- a/arch/loongarch/net/bpf_jit.c
> +++ b/arch/loongarch/net/bpf_jit.c
> @@ -1514,6 +1514,12 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
>         if (m->nr_args > LOONGARCH_MAX_REG_ARGS)
>                 return -ENOTSUPP;
>
> +       /* don't support struct argument */
> +       for (i = 0; i < m->nr_args; i++) {
> +               if (m->arg_flags[i] & BTF_FMODEL_STRUCT_ARG)
> +                       return -ENOTSUPP;
> +       }
> +
>         if (flags & (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY))
>                 return -ENOTSUPP;
>
> --
> 2.43.5
>
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly
  2025-08-28  9:24     ` Hengqi Chen
@ 2025-08-28 10:40       ` Jinyang He
  0 siblings, 0 replies; 10+ messages in thread
From: Jinyang He @ 2025-08-28 10:40 UTC (permalink / raw)
  To: Hengqi Chen
  Cc: chenhuacai, yangtiezhu, jianghaoran, duanchenghao, ast, daniel,
	andrii, martin.lau, vincent.mc.li, bpf, loongarch

On 2025-08-28 17:24, Hengqi Chen wrote:

> On Thu, Aug 28, 2025 at 2:11 PM Jinyang He <hejinyang@loongson.cn> wrote:
>> On 2025-08-27 17:47, Hengqi Chen wrote:
>>
>>> The ns_bpf_qdisc selftest triggers a kernel panic:
>>>
>>>       CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4
>>>       Oops[#1]:
>>>       CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G           OE       6.16.0+ #3 PREEMPT(full)
>>>       Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>>>       Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
>>>       pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600
>>>       a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008
>>>       a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000
>>>       t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001
>>>       t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d
>>>       t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800
>>>       s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880
>>>       s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000
>>>          ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8
>>>         ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8
>>>        CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
>>>        PRMD: 00000004 (PPLV0 +PIE -PWE)
>>>        EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
>>>        ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
>>>       ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
>>>        BADV: 0000000000741d58
>>>        PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
>>>       Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]
>>>       Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)
>>>       Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8
>>>               90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000
>>>               900000010597c400 900000008694a000 0000000000000000 9000000105b59000
>>>               90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c
>>>               9000000086936000 0000000100094d4c fffffff400676208 0000000000000000
>>>               9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000
>>>               9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000
>>>               9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840
>>>               0000000000000000 9000000086be6c40 0000000000000000 0000000000000000
>>>               0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4
>>>               ...
>>>       Call Trace:
>>>       [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8
>>>       [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0
>>>       [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950
>>>       [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448
>>>       [<9000000085370b24>] ip6_xmit+0x304/0x858
>>>       [<90000000853c4438>] inet6_csk_xmit+0x100/0x170
>>>       [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0
>>>       [<90000000852b47fc>] tcp_connect+0xbcc/0x1168
>>>       [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0
>>>       [<90000000852e7738>] __inet_stream_connect+0x170/0x480
>>>       [<90000000852e7a98>] inet_stream_connect+0x50/0x88
>>>       [<90000000850f2814>] __sys_connect+0xe4/0x110
>>>       [<90000000850f2858>] sys_connect+0x18/0x28
>>>       [<9000000085520c94>] do_syscall+0x94/0x1a0
>>>       [<9000000083df1fb8>] handle_syscall+0xb8/0x158
>>>
>>>       Code: 4001ad80  2400873f  2400832d <240073cc> 001137ff  001133ff  6407b41f  001503cc  0280041d
>>>
>>>       ---[ end trace 0000000000000000 ]---
>>>
>>> The bpf_fifo_dequeue prog returns a skb which is a pointer.
>>> The pointer is treated as a 32bit value and sign extend to
>>> 64bit in epilogue. This behavior is right for most bpf prog
>>> types but wrong for struct ops which requires LoongArch ABI.
>>>
>>> So let's sign extend struct ops return values according to
>>> the return value spec in function model.
>>>
>>> Fixes: 6abf17d690d8 ("LoongArch: BPF: Add struct ops support for trampoline")
>>> Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
>>> Tested-by: Vincent Li <vincent.mc.li@gmail.com>
>>> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
>>> ---
>>>    arch/loongarch/net/bpf_jit.c | 26 ++++++++++++++++++++++++++
>>>    1 file changed, 26 insertions(+)
>>>
>>> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
>>> index b646c6b73014..c239e5ed0c92 100644
>>> --- a/arch/loongarch/net/bpf_jit.c
>>> +++ b/arch/loongarch/net/bpf_jit.c
>>> @@ -1448,6 +1448,28 @@ void arch_free_bpf_trampoline(void *image, unsigned int size)
>>>        bpf_prog_pack_free(image, size);
>>>    }
>>>
>>> +/*
>>> + * Sign-extend the register if necessary
>>> + */
>>> +static void sign_extend(struct jit_ctx *ctx, int r, u8 size)
>>> +{
>>> +     switch (size) {
>>> +     case 1:
>>> +             emit_insn(ctx, extwb, r, r);
>>> +             break;
>>> +     case 2:
>>> +             emit_insn(ctx, extwh, r, r);
>>> +             break;
>>> +     case 4:
>>> +             emit_insn(ctx, addiw, r, r, 0);
>>> +             break;
>>> +     case 8:
>>> +             break;
>>> +     default:
>>> +             pr_warn("bpf_jit: invalid size %d for sign_extend\n", size);
>>> +     }
>>> +}
>>> +
>>>    static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
>>>                                         const struct btf_func_model *m, struct bpf_tramp_links *tlinks,
>>>                                         void *func_addr, u32 flags)
>>> @@ -1654,6 +1676,10 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
>>>        if (save_ret) {
>>>                emit_insn(ctx, ldd, LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -retval_off);
>>>                emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP, -(retval_off - 8));
>>> +             if (is_struct_ops) {
>>> +                     move_reg(ctx, LOONGARCH_GPR_A0, regmap[BPF_REG_0]);
>>> +                     sign_extend(ctx, LOONGARCH_GPR_A0, m->ret_size);
>>> +             }
>>>        }
>> Hi, Hengqi,
>>
>> It can be did same as Tiezhu's patch, named "LoongArch: BPF: Optimize
>> sign-extention mov instructions", which use only one sign-extend
>> instruction.
>>
>> And btw, how about,
>> if (save_ret) {
>>     if (is_struct_ops) {
>>       ld.{d,w,h,b} LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -(retval_off - 8)
>>       emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP,
>> -(retval_off - 8)); // I don't know is it needed.
>>     } else {
>>       emit_insn(ctx, ldd, LOONGARCH_GPR_A0, LOONGARCH_GPR_FP, -retval_off);
>>       emit_insn(ctx, ldd, regmap[BPF_REG_0], LOONGARCH_GPR_FP,
>> -(retval_off - 8));
>>     }
> Hmm, how about:
>
> static void sign_extend(struct jit_ctx *ctx, int rd, int rj, u8 size)
>
> and sign extend regmap[BPF_REG_0] to LOONGARCH_GPR_A0

Up to you. I just give an idea for reduce instruction count.
It won't change result. For readability, this is better.

>
>> }
>>>        emit_insn(ctx, ldd, LOONGARCH_GPR_S1, LOONGARCH_GPR_FP, -sreg_off);


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 3/3] LoongArch: BPF: No support of struct argument in trampoline programs
  2025-08-28  9:26   ` Huacai Chen
@ 2025-08-28 11:03     ` Hengqi Chen
  0 siblings, 0 replies; 10+ messages in thread
From: Hengqi Chen @ 2025-08-28 11:03 UTC (permalink / raw)
  To: Huacai Chen
  Cc: yangtiezhu, jianghaoran, duanchenghao, ast, daniel, andrii,
	martin.lau, vincent.mc.li, bpf, loongarch

On Thu, Aug 28, 2025 at 5:26 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> On Wed, Aug 27, 2025 at 7:19 PM Hengqi Chen <hengqi.chen@gmail.com> wrote:
> >
> > The current implementation does not support struct argument.
> > This cause a oops when running bpf selftest:
> >
> >     $ ./test_progs -a tracing_struct
> >     CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 90000000845659f4, ra == 90000000845659e8
> >     Oops[#1]:
> >     CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938
> >     rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> >     rcu:     1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801
> >     rcu:     (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)
> >     Sending NMI from CPU 0 to CPUs 1:
> >     rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2
> >     rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
> >     rcu: RCU grace-period kthread stack dump:
> >     task:rcu_preempt     state:I stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000800
> >     Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680
> >             9000000085d88000 0000000000000000 0000000000000040 9000000087159350
> >             9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005
> >             00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004
> >             9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e
> >             00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350
> >             900000008715bf98 0000000000000005 9000000087036000 900000008704a000
> >             9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0
> >             00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000
> >             9000000007002150 00000000ffff355b 9000000084615480 0000000007000002
> >             ...
> >     Call Trace:
> >     [<9000000085c2a868>] __schedule+0x410/0x1520
> >     [<9000000085c2b9ac>] schedule+0x34/0x190
> >     [<9000000085c33d38>] schedule_timeout+0x98/0x140
> >     [<90000000845e9120>] rcu_gp_fqs_loop+0x5f8/0x868
> >     [<90000000845ed538>] rcu_gp_kthread+0x260/0x2e0
> >     [<900000008454e8a4>] kthread+0x144/0x238
> >     [<9000000085c26b60>] ret_from_kernel_thread+0x28/0xc8
> >     [<90000000844f20e4>] ret_from_kernel_thread_asm+0xc/0x88
> >
> >     rcu: Stack dump where RCU GP kthread last ran:
> >     Sending NMI from CPU 0 to CPUs 2:
> >     NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4
> >
> > Reject it for now.
> Drop this patch or pick Tiezhu's patches as a single series?
> https://lore.kernel.org/loongarch/20250821144302.14010-1-yangtiezhu@loongson.cn/T/#t
>

Tiezhu's patch does not work for now unless we fix the module_attach issue.

> Huacai
>
> >
> > Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support")
> > Acked-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> > Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> > Tested-by: Vincent Li <vincent.mc.li@gmail.com>
> > Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
> > ---
> >  arch/loongarch/net/bpf_jit.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> > index c239e5ed0c92..66b102ed9874 100644
> > --- a/arch/loongarch/net/bpf_jit.c
> > +++ b/arch/loongarch/net/bpf_jit.c
> > @@ -1514,6 +1514,12 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i
> >         if (m->nr_args > LOONGARCH_MAX_REG_ARGS)
> >                 return -ENOTSUPP;
> >
> > +       /* don't support struct argument */
> > +       for (i = 0; i < m->nr_args; i++) {
> > +               if (m->arg_flags[i] & BTF_FMODEL_STRUCT_ARG)
> > +                       return -ENOTSUPP;
> > +       }
> > +
> >         if (flags & (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY))
> >                 return -ENOTSUPP;
> >
> > --
> > 2.43.5
> >
> >
> >

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2025-08-28 11:03 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-27  9:47 [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Hengqi Chen
2025-08-27  9:47 ` [PATCH v2 1/3] LoongArch: BPF: Remove duplicated flags check Hengqi Chen
2025-08-27  9:47 ` [PATCH v2 2/3] LoongArch: BPF: Sign extend struct ops return values properly Hengqi Chen
2025-08-28  6:11   ` Jinyang He
2025-08-28  9:24     ` Hengqi Chen
2025-08-28 10:40       ` Jinyang He
2025-08-27  9:47 ` [PATCH v2 3/3] LoongArch: BPF: No support of struct argument in trampoline programs Hengqi Chen
2025-08-28  9:26   ` Huacai Chen
2025-08-28 11:03     ` Hengqi Chen
2025-08-27 14:22 ` [PATCH v2 0/3] LoongArch: Fix BPF trampoline related issues Vincent Li

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).