Thread (7 messages) 7 messages, 3 authors, 14d ago

Re: [PATCH V5 2/2] rust: kernel: Add KUnit tests for powerpc ARCH_WARN_ASM bug table emission

From: Mukesh Kumar Chaurasiya <hidden>
Date: 2026-09-16 14:18:22
Also in: linux-riscv, lkml, llvm, rust-for-linux

On Wed, Sep 16, 2026 at 11:06:58PM +0900, FUJITA Tomonori wrote:
On Tue, 15 Sep 2026 14:34:53 +0530
"Mukesh Kumar Chaurasiya (IBM)" [off-list ref] wrote:
quoted
Verify that the __bug_table entry emitted by ARCH_WARN_ASM has a correct
bug_addr displacement ― i.e. the '1b' label reference in _EMIT_BUG_ENTRY
resolves to the trap instruction ― by calling find_bug() with the exact
virtual address of the twi instruction, mirroring what the real powerpc
trap handler does.

The trap address is captured at link time via a .dc.a 1b relocation placed
in .data by the global_asm! block. global_asm! is used instead of asm!
because LLVM eliminates asm! blocks in dead branches; global_asm! is
file-scope and always emitted. BUG_KUNIT_TRAP_ADDR is defined as a .global
symbol directly on the .dc.a word so the linker relocation lands on it ―
a Rust static initialized to zero would end up in BSS where relocations are
not applied.

.dc.a emits a pointer-width word (4 bytes on ppc32, 8 bytes on ppc64),
so BUG_KUNIT_TRAP_ADDR is declared as usize on the Rust side, making the
tests correct on both ppc32 and ppc64. The global_asm! block is split into
two cfg-gated variants (CONFIG_PPC64 / !CONFIG_PPC64) to select the right
.balign since concat!() only accepts literals.

Five tests are included in the rust_kernel_bug_powerpc suite:

  bug_entry_found         - find_bug() returns non-NULL for the trap address,
                            proving the bug_addr displacement is correct
  bug_entry_is_warning    - the emitted entry has BUGFLAG_WARNING set
  bug_entry_file          - bug_get_file_line() returns the correct source
                            file (requires CONFIG_DEBUG_BUGVERBOSE)
  bug_entry_line          - the recorded line number is non-zero, confirming
                            the {line} operand was substituted correctly
                            (requires CONFIG_DEBUG_BUGVERBOSE)
  bug_entry_addr_is_in_text - kernel_text_address() confirms the trap address
                            lies in kernel text, not data or zero

The suite is named rust_kernel_bug_powerpc and the Kconfig option
CONFIG_RUST_BUG_POWERPC_KUNIT_TEST depends on PPC && GENERIC_BUG,
covering both ppc32 and ppc64.

Tested on ppc64le (ltcfujiaac-lp3, 7.3.0-rc1+): pass:5 fail:0 skip:0.
Tested on ppc32 Book3S (QEMU mac99 G4, chrp32_defconfig): pass:5 fail:0 skip:0.
Tested on ppc64le (QEMU pseries, pseries_le_defconfig): pass:5 fail:0 skip:0.

Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
---
 rust/kernel/Kconfig.test |  13 +++
 rust/kernel/bug.rs       | 209 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 222 insertions(+)
I think that testing warn_on!, in particular that the right address is
put in the bug entry, is a good idea.

I'd prefer such a test to work on every architecture. This one depends on
details of powerpc's ARCH_WARN_ASM, such as the '1b' label. KUnit has a
warning suppression API. A test can call warn_on! inside a suppression
block and check that one warning was counted. The counter is only
incremented after find_bug() found the entry, so a wrong address is caught
too.

I'll send a patch for that shortly.
yeah,

makes sense.

Regards,
Mukesh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help