arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+)
Clang misaligns the test_kprobes_addresses and test_kprobes_functions
arrays, or does not export local labels by default. Both can cause
kmalloc_array() allocation errors and KUnit failures.
This patch fixes the issue by:
- Adding .section .rodata to explicitly place arrays in the read-only data segment.
- Adding .align 3 to align arrays to 8 bytes.
- Adding .globl to probe labels to ensure symbols are visible.
For detailed debug and analysis, see:
https://github.com/j1akai/temp/blob/main/20251113/readme.md
Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn>
---
arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S b/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S
index b951d0f12482..ac5ce305b1bd 100644
--- a/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S
+++ b/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S
@@ -7,8 +7,10 @@
SYM_FUNC_START(test_kprobes_add)
li a1, KPROBE_TEST_MAGIC_UPPER
li a2, KPROBE_TEST_MAGIC_LOWER
+.globl test_kprobes_add_addr1
test_kprobes_add_addr1:
add a1, a1, a2
+.globl test_kprobes_add_addr2
test_kprobes_add_addr2:
add a0, a1, x0
ret
@@ -19,6 +21,7 @@ SYM_FUNC_START(test_kprobes_jal)
mv a1, ra
.option push
.option norvc
+.globl test_kprobes_jal_addr1
test_kprobes_jal_addr1:
jal x0, 2f
ret
@@ -27,6 +30,7 @@ test_kprobes_jal_addr1:
ret
.option push
.option norvc
+.globl test_kprobes_jal_addr2
test_kprobes_jal_addr2:
2: jal 1b
.option pop
@@ -40,6 +44,7 @@ SYM_FUNC_START(test_kprobes_jalr)
mv a1, ra
.option push
.option norvc
+.globl test_kprobes_jalr_addr
test_kprobes_jalr_addr:
jalr a0
.option pop
@@ -51,6 +56,7 @@ test_kprobes_jalr_addr:
SYM_FUNC_END(test_kprobes_jalr)
SYM_FUNC_START(test_kprobes_auipc)
+.globl test_kprobes_auipc_addr
test_kprobes_auipc_addr:
auipc a0, KPROBE_TEST_MAGIC_LOWER
la a1, test_kprobes_auipc_addr
@@ -67,20 +73,26 @@ SYM_FUNC_START(test_kprobes_branch)
li a0, 0
li a1, 1
li a2, 2
+.globl test_kprobes_branch_addr1
test_kprobes_branch_addr1:
beqz a0, 1f
ret
1:
+.globl test_kprobes_branch_addr2
test_kprobes_branch_addr2:
beqz a1, 3f
+.globl test_kprobes_branch_addr3
test_kprobes_branch_addr3:
bnez a0, 3f
+.globl test_kprobes_branch_addr4
test_kprobes_branch_addr4:
bnez a2, 1f
ret
1:
+.globl test_kprobes_branch_addr5
test_kprobes_branch_addr5:
bge a1, a2, 3f
+.globl test_kprobes_branch_addr6
test_kprobes_branch_addr6:
bge a2, a1, 2f
ret
@@ -89,9 +101,11 @@ test_kprobes_branch_addr6:
add a0, a0, t0
ret
2:
+.globl test_kprobes_branch_addr7
test_kprobes_branch_addr7:
blt a2, a1, 3f
li a0, KPROBE_TEST_MAGIC_LOWER
+.globl test_kprobes_branch_addr8
test_kprobes_branch_addr8:
blt a1, a2, 1b
3:
@@ -104,6 +118,7 @@ SYM_FUNC_END(test_kprobes_branch)
SYM_FUNC_START(test_kprobes_c_j)
li a0, 0
+.globl test_kprobes_branch_c_j_addr1
test_kprobes_branch_c_j_addr1:
c.j 2f
1:
@@ -111,12 +126,14 @@ test_kprobes_branch_c_j_addr1:
add a0, a0, a1
ret
2: li a0, KPROBE_TEST_MAGIC_LOWER
+.globl test_kprobes_branch_c_j_addr2
test_kprobes_branch_c_j_addr2:
c.j 1b
SYM_FUNC_END(test_kprobes_c_j)
SYM_FUNC_START(test_kprobes_c_jr)
la a0, 2f
+.globl test_kprobes_c_jr_addr1
test_kprobes_c_jr_addr1:
c.jr a0
ret
@@ -126,6 +143,7 @@ test_kprobes_c_jr_addr1:
2:
li a0, KPROBE_TEST_MAGIC_UPPER
la a1, 1b
+.globl test_kprobes_c_jr_addr2
test_kprobes_c_jr_addr2:
c.jr a1
SYM_FUNC_END(test_kprobes_c_jr)
@@ -133,6 +151,7 @@ SYM_FUNC_END(test_kprobes_c_jr)
SYM_FUNC_START(test_kprobes_c_jalr)
mv a1, ra
la a0, 1f
+.globl test_kprobes_c_jalr_addr
test_kprobes_c_jalr_addr:
c.jalr a0
li a2, KPROBE_TEST_MAGIC_UPPER
@@ -145,16 +164,19 @@ SYM_FUNC_END(test_kprobes_c_jalr)
SYM_FUNC_START(test_kprobes_c_beqz)
li a0, 0
li a1, 1
+.globl test_kprobes_c_beqz_addr1
test_kprobes_c_beqz_addr1:
c.beqz a0, 2f
ret
1: li a1, KPROBE_TEST_MAGIC_UPPER
add a0, a0, a1
ret
+.globl test_kprobes_c_beqz_addr2
test_kprobes_c_beqz_addr2:
2: c.beqz a1, 3f
li a0, KPROBE_TEST_MAGIC_LOWER
mv a1, x0
+.globl test_kprobes_c_beqz_addr3
test_kprobes_c_beqz_addr3:
c.beqz a1, 1b
3: li a0, 0
@@ -164,15 +186,18 @@ SYM_FUNC_END(test_kprobes_c_beqz)
SYM_FUNC_START(test_kprobes_c_bnez)
li a0, 0
li a1, 1
+.globl test_kprobes_c_bnez_addr1
test_kprobes_c_bnez_addr1:
c.bnez a1, 2f
ret
1: li a1, KPROBE_TEST_MAGIC_UPPER
add a0, a0, a1
ret
+.globl test_kprobes_c_bnez_addr2
test_kprobes_c_bnez_addr2:
2: c.bnez a0, 3f
li a0, KPROBE_TEST_MAGIC_LOWER
+.globl test_kprobes_c_bnez_addr3
test_kprobes_c_bnez_addr3:
c.bnez a0, 1b
3: li a0, 0
@@ -181,6 +206,8 @@ SYM_FUNC_END(test_kprobes_c_bnez)
#endif /* CONFIG_RISCV_ISA_C */
+.section .rodata
+.align 3
SYM_DATA_START(test_kprobes_addresses)
RISCV_PTR test_kprobes_add_addr1
RISCV_PTR test_kprobes_add_addr2
@@ -212,6 +239,8 @@ SYM_DATA_START(test_kprobes_addresses)
RISCV_PTR 0
SYM_DATA_END(test_kprobes_addresses)
+.section .rodata
+.align 3
SYM_DATA_START(test_kprobes_functions)
RISCV_PTR test_kprobes_add
RISCV_PTR test_kprobes_jal
--
2.34.1
</xujiakai2025@iscas.ac.cn>许佳凯 <xujiakai2025@iscas.ac.cn> writes: > Clang misaligns the test_kprobes_addresses and test_kprobes_functions > arrays, or does not export local labels by default. Both can cause > kmalloc_array() allocation errors and KUnit failures. > > This patch fixes the issue by: > - Adding .section .rodata to explicitly place arrays in the read-only data segment. > - Adding .align 3 to align arrays to 8 bytes. > - Adding .globl to probe labels to ensure symbols are visible. We do not have to make it exactly the same as building with GCC, right? Only moving the arrays to .rodata seems sufficient to fix the issue, but I cannot explain why yet. What I observed is that with CONFIG_RELOCATABLE=y, the kernel's .rela.dyn section, which holds the relocation entries for the two arrays, have incorrect addresses (they are all incorrectly offset by 6 bytes for my build). The kernel uses these relocation information to fill the arrays during boot, and fill them at wrong addresses. I smell a linker problem, but more investigation needed... Nam
Nam Cao <namcao@linutronix.de> writes: > 许佳凯 <xujiakai2025@iscas.ac.cn> writes: >> Clang misaligns the test_kprobes_addresses and test_kprobes_functions >> arrays, or does not export local labels by default. Both can cause >> kmalloc_array() allocation errors and KUnit failures. >> >> This patch fixes the issue by: >> - Adding .section .rodata to explicitly place arrays in the read-only data segment. >> - Adding .align 3 to align arrays to 8 bytes. >> - Adding .globl to probe labels to ensure symbols are visible. > > We do not have to make it exactly the same as building with GCC, right? > Only moving the arrays to .rodata seems sufficient to fix the issue, but > I cannot explain why yet. > > What I observed is that with CONFIG_RELOCATABLE=y, the kernel's > .rela.dyn section, which holds the relocation entries for the two > arrays, have incorrect addresses (they are all incorrectly offset by 6 > bytes for my build). The kernel uses these relocation information to > fill the arrays during boot, and fill them at wrong addresses. > > I smell a linker problem, but more investigation needed... I sent my findings to LLVM folks: https://github.com/llvm/llvm-project/issues/168308#issuecomment-3582596694 I suspect linker problem. But let's see what LLVM people think. Nam
+ Nam Cao, Nathan Chancellor
On Thu, 13 Nov 2025, 许佳凯 wrote:
> Clang misaligns the test_kprobes_addresses and test_kprobes_functions
> arrays, or does not export local labels by default. Both can cause
> kmalloc_array() allocation errors and KUnit failures.
>
> This patch fixes the issue by:
> - Adding .section .rodata to explicitly place arrays in the read-only data segment.
> - Adding .align 3 to align arrays to 8 bytes.
> - Adding .globl to probe labels to ensure symbols are visible.
>
> For detailed debug and analysis, see:
> https://github.com/j1akai/temp/blob/main/20251113/readme.md
>
> Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn>
Hello Jiakai Xu,
Thanks for the patch. Have you reported this difference in behavior to
the Clang/LLVM folks so they can render an opinion on it? We can consider
this as a short term workaround if it's indeed a toolchain issue, but I'd
like to hear from the LLVM folks.
Also: could you please include the narrative from your page
https://github.com/j1akai/temp/blob/main/20251113/readme.md
in the patch description, just in case that URL eventually becomes
unavailable?
thanks,
- Paul
Hello Paul,
Thank you very much for reviewing my patch; your feedback was very helpful.
> Thanks for the patch. Have you reported this difference in behavior to
> the Clang/LLVM folks so they can render an opinion on it? We can consider
> this as a short term workaround if it's indeed a toolchain issue, but I'd
> like to hear from the LLVM folks.
I have reported this issue to the LLVM community:
https://github.com/llvm/llvm-project/issues/168308
We now need to wait for feedback from the LLVM community.
>
> Also: could you please include the narrative from your page
>
> https://github.com/j1akai/temp/blob/main/20251113/readme.md
>
> in the patch description, just in case that URL eventually becomes
> unavailable?
Below, I include the narrative from my readme for reference:
---
Kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/snapshot/linux-riscv-for-linus-6.18-rc6.tar.gz
Configuration:
https://github.com/j1akai/temp/blob/main/20251113/config.log
LLVM:
https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.5/LLVM-21.1.5-Linux-X64.tar.xz
When booting the kernel in QEMU, the error was traced to:
`arch/riscv/kernel/tests/kprobes`. Log:
https://github.com/j1akai/temp/blob/main/20251113/report0.log
Specifically, in the file `arch/riscv/kernel/tests/kprobes/test-kprobes.c`,
the following line fails:
```c
kp = kcalloc(num_kprobe, sizeof(*kp), GFP_KERNEL);
```
I added debugging output:
```c
while (test_kprobes_addresses[num_kprobe]) {
pr_info("addr[%d] = %px\n", num_kprobe,
test_kprobes_addresses[num_kprobe]);
num_kprobe++;
}
pr_info("num_kprobe=%u\n", num_kprobe);
```
This revealed that the length of the `test_kprobes_addresses` array is
abnormally large. See:
https://github.com/j1akai/temp/blob/main/20251113/vm.log
According to the file `arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S`,
only 25 entries should be inserted into `test_kprobes_addresses`. Therefore,
the array should not be this long.
When compiling the kernel with GCC, the kernel boots correctly. This indicates
that the issue is specific to Clang: Clang misaligns the arrays or generates
symbols incorrectly, causing `test_kprobes_addresses` to appear much larger than
it actually is, even containing invalid addresses. Consequently, the loop
```c
while(test_kprobes_addresses[num_kprobe])
```
overestimates `num_kprobe`, and `kcalloc` tries to allocate an excessively
large memory block.
The solution is to explicitly apply `.align 3` (8-byte alignment) to both
`test_kprobes_addresses` and `test_kprobes_functions`, place them in `.rodata`,
and declare the symbols as global using `.globl` to ensure consistent behavior
between Clang and GCC.
---
I would like to ask whether it is appropriate to
include all this detail directly in the patch description and email,
or if it would be better to submit it as a PATCH v1.
Thank you again for your guidance.
- Jiaki Xu
Hi, On Mon, 17 Nov 2025, Jiakai Xu wrote: > Thank you very much for reviewing my patch; your feedback was very helpful. Great. Here's one more request: > > Thanks for the patch. Have you reported this difference in behavior to Looks like you're using a mail client that sends HTML in what should be a plain-text E-mail; please fix that. > I have reported this issue to the LLVM community: > https://github.com/llvm/llvm-project/issues/168308 > We now need to wait for feedback from the LLVM community. Thank you. > Below, I include the narrative from my readme for reference: [ ... ] > I would like to ask whether it is appropriate to include all this detail > directly in the patch description and email, or if it would be better to > submit it as a PATCH v1. Not all of it, but some edited summary is appropriate. I've queued the following revision for v6.18-rc fixes, under the theory that it would be good to get the test working for Clang users while the LLVM folks investigate. Please let us know ASAP if you think anything in it should be changed. I plan to send a PR out later this week. thanks, - Paul From: =?UTF-8?q?=E8=AE=B8=E4=BD=B3=E5=87=AF?= <xujiakai2025@iscas.ac.cn> Date: Thu, 13 Nov 2025 18:51:42 +0800 Subject: [PATCH] riscv: fix KUnit test_kprobes crash when building with Clang Clang misaligns the test_kprobes_addresses and test_kprobes_functions arrays, or does not export local labels by default. Both can cause kmalloc_array() allocation errors and KUnit failures. When testing the Clang-compiled code in QEMU, this warning was emitted: WARNING: CPU: 1 PID: 3000 at mm/page_alloc.c:5159 __alloc_frozen_pages_noprof+0xe6/0x2fc mm/page_alloc.c:5159 Further investigation revealed that the test_kprobes_addresses array appeared to have over 100,000 elements, including invalid addresses; whereas, according to test-kprobes-asm.S, test_kprobes_addresses should only have 25 elements. When compiling the kernel with GCC, the kernel boots correctly. This patch fixes the issue by: - Adding .section .rodata to explicitly place arrays in the read-only data segment. - Adding .align 3 to align arrays to 8 bytes. - Adding .globl to probe labels to ensure symbols are visible. For detailed debug and analysis, see: https://github.com/j1akai/temp/blob/main/20251113/readme.md Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Link: https://patch.msgid.link/738dd4e2.ff73.19a7cd7b4d5.Coremail.xujiakai2025@iscas.ac.cn Link: https://github.com/llvm/llvm-project/issues/168308 Cc: Nam Cao <namcao@linutronix.de> [pjw@kernel.org: added additional context to the patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> --- .../kernel/tests/kprobes/test-kprobes-asm.S | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S b/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S index b951d0f12482..ac5ce305b1bd 100644 --- a/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S +++ b/arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S @@ -7,8 +7,10 @@ SYM_FUNC_START(test_kprobes_add) li a1, KPROBE_TEST_MAGIC_UPPER li a2, KPROBE_TEST_MAGIC_LOWER +.globl test_kprobes_add_addr1 test_kprobes_add_addr1: add a1, a1, a2 +.globl test_kprobes_add_addr2 test_kprobes_add_addr2: add a0, a1, x0 ret @@ -19,6 +21,7 @@ SYM_FUNC_START(test_kprobes_jal) mv a1, ra .option push .option norvc +.globl test_kprobes_jal_addr1 test_kprobes_jal_addr1: jal x0, 2f ret @@ -27,6 +30,7 @@ test_kprobes_jal_addr1: ret .option push .option norvc +.globl test_kprobes_jal_addr2 test_kprobes_jal_addr2: 2: jal 1b .option pop @@ -40,6 +44,7 @@ SYM_FUNC_START(test_kprobes_jalr) mv a1, ra .option push .option norvc +.globl test_kprobes_jalr_addr test_kprobes_jalr_addr: jalr a0 .option pop @@ -51,6 +56,7 @@ test_kprobes_jalr_addr: SYM_FUNC_END(test_kprobes_jalr) SYM_FUNC_START(test_kprobes_auipc) +.globl test_kprobes_auipc_addr test_kprobes_auipc_addr: auipc a0, KPROBE_TEST_MAGIC_LOWER la a1, test_kprobes_auipc_addr @@ -67,20 +73,26 @@ SYM_FUNC_START(test_kprobes_branch) li a0, 0 li a1, 1 li a2, 2 +.globl test_kprobes_branch_addr1 test_kprobes_branch_addr1: beqz a0, 1f ret 1: +.globl test_kprobes_branch_addr2 test_kprobes_branch_addr2: beqz a1, 3f +.globl test_kprobes_branch_addr3 test_kprobes_branch_addr3: bnez a0, 3f +.globl test_kprobes_branch_addr4 test_kprobes_branch_addr4: bnez a2, 1f ret 1: +.globl test_kprobes_branch_addr5 test_kprobes_branch_addr5: bge a1, a2, 3f +.globl test_kprobes_branch_addr6 test_kprobes_branch_addr6: bge a2, a1, 2f ret @@ -89,9 +101,11 @@ test_kprobes_branch_addr6: add a0, a0, t0 ret 2: +.globl test_kprobes_branch_addr7 test_kprobes_branch_addr7: blt a2, a1, 3f li a0, KPROBE_TEST_MAGIC_LOWER +.globl test_kprobes_branch_addr8 test_kprobes_branch_addr8: blt a1, a2, 1b 3: @@ -104,6 +118,7 @@ SYM_FUNC_END(test_kprobes_branch) SYM_FUNC_START(test_kprobes_c_j) li a0, 0 +.globl test_kprobes_branch_c_j_addr1 test_kprobes_branch_c_j_addr1: c.j 2f 1: @@ -111,12 +126,14 @@ test_kprobes_branch_c_j_addr1: add a0, a0, a1 ret 2: li a0, KPROBE_TEST_MAGIC_LOWER +.globl test_kprobes_branch_c_j_addr2 test_kprobes_branch_c_j_addr2: c.j 1b SYM_FUNC_END(test_kprobes_c_j) SYM_FUNC_START(test_kprobes_c_jr) la a0, 2f +.globl test_kprobes_c_jr_addr1 test_kprobes_c_jr_addr1: c.jr a0 ret @@ -126,6 +143,7 @@ test_kprobes_c_jr_addr1: 2: li a0, KPROBE_TEST_MAGIC_UPPER la a1, 1b +.globl test_kprobes_c_jr_addr2 test_kprobes_c_jr_addr2: c.jr a1 SYM_FUNC_END(test_kprobes_c_jr) @@ -133,6 +151,7 @@ SYM_FUNC_END(test_kprobes_c_jr) SYM_FUNC_START(test_kprobes_c_jalr) mv a1, ra la a0, 1f +.globl test_kprobes_c_jalr_addr test_kprobes_c_jalr_addr: c.jalr a0 li a2, KPROBE_TEST_MAGIC_UPPER @@ -145,16 +164,19 @@ SYM_FUNC_END(test_kprobes_c_jalr) SYM_FUNC_START(test_kprobes_c_beqz) li a0, 0 li a1, 1 +.globl test_kprobes_c_beqz_addr1 test_kprobes_c_beqz_addr1: c.beqz a0, 2f ret 1: li a1, KPROBE_TEST_MAGIC_UPPER add a0, a0, a1 ret +.globl test_kprobes_c_beqz_addr2 test_kprobes_c_beqz_addr2: 2: c.beqz a1, 3f li a0, KPROBE_TEST_MAGIC_LOWER mv a1, x0 +.globl test_kprobes_c_beqz_addr3 test_kprobes_c_beqz_addr3: c.beqz a1, 1b 3: li a0, 0 @@ -164,15 +186,18 @@ SYM_FUNC_END(test_kprobes_c_beqz) SYM_FUNC_START(test_kprobes_c_bnez) li a0, 0 li a1, 1 +.globl test_kprobes_c_bnez_addr1 test_kprobes_c_bnez_addr1: c.bnez a1, 2f ret 1: li a1, KPROBE_TEST_MAGIC_UPPER add a0, a0, a1 ret +.globl test_kprobes_c_bnez_addr2 test_kprobes_c_bnez_addr2: 2: c.bnez a0, 3f li a0, KPROBE_TEST_MAGIC_LOWER +.globl test_kprobes_c_bnez_addr3 test_kprobes_c_bnez_addr3: c.bnez a0, 1b 3: li a0, 0 @@ -181,6 +206,8 @@ SYM_FUNC_END(test_kprobes_c_bnez) #endif /* CONFIG_RISCV_ISA_C */ +.section .rodata +.align 3 SYM_DATA_START(test_kprobes_addresses) RISCV_PTR test_kprobes_add_addr1 RISCV_PTR test_kprobes_add_addr2 @@ -212,6 +239,8 @@ SYM_DATA_START(test_kprobes_addresses) RISCV_PTR 0 SYM_DATA_END(test_kprobes_addresses) +.section .rodata +.align 3 SYM_DATA_START(test_kprobes_functions) RISCV_PTR test_kprobes_add RISCV_PTR test_kprobes_jal -- 2.48.1
Hi, Paul > Looks like you're using a mail client that sends HTML in what should be a > plain-text E-mail; please fix that. I apologize for that oversight. I will make sure to use plain-text emails going forward. > Not all of it, but some edited summary is appropriate. I've queued the > following revision for v6.18-rc fixes, under the theory that it would be > good to get the test working for Clang users while the LLVM folks > investigate. Please let us know ASAP if you think anything in it should > be changed. I plan to send a PR out later this week. Thank you for your review of the patch and for the time and effort you spent on it. I fully agree with the modifications you made to the patch description. Thanks again for your guidance and support. thanks, - Jiakai
On Wed, 19 Nov 2025, Jiakai Xu wrote: > > Looks like you're using a mail client that sends HTML in what should be a > > plain-text E-mail; please fix that. > > I apologize for that oversight. > I will make sure to use plain-text emails going forward. Looks like there's still a problem (the ">"s above). > > Not all of it, but some edited summary is appropriate. I've queued the > > following revision for v6.18-rc fixes, under the theory that it would be > > good to get the test working for Clang users while the LLVM folks > > investigate. Please let us know ASAP if you think anything in it should > > be changed. I plan to send a PR out later this week. > > Thank you for your review of the patch and for the time and effort > you spent on it. I fully agree with the modifications you made to the patch > description. Looks like some of the LLVM folks have responded to https://github.com/llvm/llvm-project/issues/168308 with some suggestions. Could you implement those and test it and update the patch? If that can be done by early next week, then we should hopefully be able to get it in before v6.18 is tagged. thanks, - Paul
Hi Paul, I am very sorry for the delayed response. Due to an issue with my email client, I did not receive your previous message. I have just submitted the v2 patch which incorporates the suggestions from the LLVM folks. Please review it at your convenience. Again, I apologize for the delay and any inconvenience this may have caused. Best regards, Jiakai
Hi Paul and Jiakai,
On Tue, Nov 18, 2025 at 01:21:50PM -0700, Paul Walmsley wrote:
> Not all of it, but some edited summary is appropriate. I've queued the
> following revision for v6.18-rc fixes, under the theory that it would be
> good to get the test working for Clang users while the LLVM folks
> investigate. Please let us know ASAP if you think anything in it should
> be changed. I plan to send a PR out later this week.
I spent some time today trying to minimize a small set of configurations
that triggers this issue on top of defconfig since that occasionally
reveals a path to head down for triage and I landed on:
$ cat arch/riscv/configs/repro.config
CONFIG_KPROBES=y
CONFIG_KUNIT=y
CONFIG_RELOCATABLE=y
CONFIG_RISCV_KPROBES_KUNIT=y
$ make -skj"$(nproc)" ARCH=riscv LLVM=1 clean defconfig repro.config Image
$ curl -LSs https://github.com/ClangBuiltLinux/boot-utils/releases/download/20241120-044434/riscv-rootfs.cpio.zst | zstd -d >rootfs.cpio
$ qemu-system-riscv64 \
-display none \
-nodefaults \
-bios default \
-M virt \
-append earlycon \
-kernel arch/riscv/boot/Image \
-initrd rootfs.cpio \
-m 512m \
-serial mon:stdio
...
[ 0.000000] Booting Linux on hartid 0
[ 0.000000] Linux version 6.18.0-rc6-dirty (nathan@ax162) (ClangBuiltLinux clang version 21.1.5 (https://github.com/llvm/llvm-project.git 8e2cd28cd4ba46613a46467b0c91b1cabead26cd), ClangBuiltLinux LLD 21.1.5 (https://github.com/llvm/llvm-project.git 8e2cd28cd4ba46613a46467b0c91b1cabead26cd)) #1 SMP Tue Nov 18 17:58:23 MST 2025
...
[ 1.041311] KTAP version 1
[ 1.041433] 1..1
[ 1.042111] KTAP version 1
[ 1.042310] # Subtest: kprobes_riscv
[ 1.042610] # module: kprobes_riscv_kunit
[ 1.042732] 1..1
[ 1.047104] ------------[ cut here ]------------
[ 1.047293] WARNING: CPU: 0 PID: 45 at mm/page_alloc.c:5159 __alloc_frozen_pages_noprof+0x160/0x228
[ 1.047602] Modules linked in:
[ 1.047851] CPU: 0 UID: 0 PID: 45 Comm: kunit_try_catch Tainted: G N 6.18.0-rc6-dirty #1 NONE
[ 1.047933] Tainted: [N]=TEST
[ 1.047948] Hardware name: riscv-virtio,qemu (DT)
[ 1.048024] epc : __alloc_frozen_pages_noprof+0x160/0x228
[ 1.048057] ra : ___kmalloc_large_node+0x52/0x1a0
[ 1.048073] epc : ffffffff8023e2e8 ra : ffffffff80247c26 sp : ff200000001f3c10
[ 1.048086] gp : ffffffff81a25900 tp : ff600000023924c0 t0 : 00000000264163d0
[ 1.048097] t1 : 00000000264163d0 t2 : 00000000000aae60 s0 : ff200000001f3c90
[ 1.048108] s1 : 000000000a83ca20 a0 : 0000000000000001 a1 : ffffffff819e71ba
[ 1.048119] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 000000003b9aca00
[ 1.048130] a5 : 0000000000016698 a6 : ff600000021480d0 a7 : 00000000000aae60
[ 1.048140] s2 : 0000000000000010 s3 : ffffffff8024857a s4 : 0000000000000dc0
[ 1.048151] s5 : ffffffff80018e20 s6 : ff2000000000bb40 s7 : 0000000000000000
[ 1.048161] s8 : 0000000000000000 s9 : 0000000000166e7c s10: 0000000000000000
[ 1.048171] s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000002
[ 1.048181] t5 : ff60000002392580 t6 : 0000000000000001
[ 1.048191] status: 0000000200000120 badaddr: ffffffff8023e2e8 cause: 0000000000000003
[ 1.048281] [<ffffffff8023e2e8>] __alloc_frozen_pages_noprof+0x160/0x228
[ 1.048362] [<ffffffff80247c26>] ___kmalloc_large_node+0x52/0x1a0
[ 1.048374] [<ffffffff80247dd8>] __kmalloc_large_node_noprof+0x1c/0x114
[ 1.048384] [<ffffffff8024857a>] __kmalloc_noprof+0x252/0x450
[ 1.048393] [<ffffffff80018ae6>] test_kprobe_riscv+0x5a/0x210
[ 1.048406] [<ffffffff8050d6a6>] kunit_try_run_case+0x5a/0x15c
[ 1.048417] [<ffffffff8050f69a>] kunit_generic_run_threadfn_adapter+0x1a/0x34
[ 1.048439] [<ffffffff8004fa88>] kthread+0x178/0x1a0
[ 1.048450] [<ffffffff8001311a>] ret_from_fork_kernel+0xe/0x48
[ 1.048464] [<ffffffff80b500f2>] ret_from_fork_kernel_asm+0x16/0x1c
[ 1.048513] ---[ end trace 0000000000000000 ]---
[ 1.056832] # test_kprobe_riscv: EXPECTATION FAILED at arch/riscv/kernel/tests/kprobes/test-kprobes.c:24
[ 1.056832] Expected kp to be true, but is false
[ 1.058370] not ok 1 test_kprobe_riscv
[ 1.058484] not ok 1 kprobes_riscv
...
This appears to happen back to LLVM 15 so I am not sure it is a recent
recent regression on the toolchain side.
Without CONFIG_RELOCATABLE enabled, the test passes:
[ 1.049384] KTAP version 1
[ 1.049656] 1..1
[ 1.050246] KTAP version 1
[ 1.050447] # Subtest: kprobes_riscv
[ 1.050760] # module: kprobes_riscv_kunit
[ 1.050867] 1..1
[ 1.061790] ok 1 test_kprobe_riscv
[ 1.061929] ok 1 kprobes_riscv
Interestingly, if I enable CONFIG_RISCV_KPROBES_KUNIT as a module, I get
a failure when trying to load it in QEMU:
~ # modprobe kprobes_riscv_kunit
[ 42.214642] kprobes_riscv_kunit: The unexpected relocation type 'R_RISCV_ALIGN' from PC = 00000000abb84ce7
[ 42.222778] kprobes_riscv_kunit: The unexpected relocation type 'R_RISCV_ALIGN' from PC = 00000000abb84ce7
modprobe: can't load module kprobes_riscv_kunit (kernel/arch/riscv/kernel/tests/kprobes/kprobes_riscv_kunit.ko): Invalid argument
which is probably unrelated but I figured it was worth mentioning, as it
does not allow me to see if this has something to do with the flags
added to LDFLAGS_vmlinux.
Maybe this is useful for the upstream report and further triage.
Cheers,
Nathan
Hi Nathan, > I spent some time today trying to minimize a small set of configurations > that triggers this issue on top of defconfig since that occasionally > reveals a path to head down for triage and I landed on: > ... Thank you for taking the time to minimize the configuration and provide the detailed reproduction steps. > This appears to happen back to LLVM 15 so I am not sure it is a recent > recent regression on the toolchain side. > > Without CONFIG_RELOCATABLE enabled, the test passes: > > [ 1.049384] KTAP version 1 > [ 1.049656] 1..1 > [ 1.050246] KTAP version 1 > [ 1.050447] # Subtest: kprobes_riscv > [ 1.050760] # module: kprobes_riscv_kunit > [ 1.050867] 1..1 > [ 1.061790] ok 1 test_kprobe_riscv > [ 1.061929] ok 1 kprobes_riscv > > Interestingly, if I enable CONFIG_RISCV_KPROBES_KUNIT as a module, I get > a failure when trying to load it in QEMU: > > ~ # modprobe kprobes_riscv_kunit > [ 42.214642] kprobes_riscv_kunit: The unexpected relocation type 'R_RISCV_ALIGN' from PC = 00000000abb84ce7 > [ 42.222778] kprobes_riscv_kunit: The unexpected relocation type 'R_RISCV_ALIGN' from PC = 00000000abb84ce7 > modprobe: can't load module kprobes_riscv_kunit (kernel/arch/riscv/kernel/tests/kprobes/kprobes_riscv_kunit.ko): Invalid argument This information is very useful for upstream triage and confirms that the issue is configuration-dependent. > which is probably unrelated but I figured it was worth mentioning, as it > does not allow me to see if this has something to do with the flags > added to LDFLAGS_vmlinux. > > Maybe this is useful for the upstream report and further triage. I really appreciate your effort in providing this data; it will definitely help with further analysis and reporting. thanks, - Jiakai
© 2016 - 2026 Red Hat, Inc.