Re: [RFC] rust: kernel: Add KUnit tests for ARCH_WARN_ASM bug table emission

From: Mark Rutland

Date: Fri Sep 25 2026 - 04:07:40 EST


On Fri, Sep 25, 2026 at 11:51:33AM +0530, Mukesh Kumar Chaurasiya wrote:
> On Thu, Sep 24, 2026 at 01:31:42PM +0100, Mark Rutland wrote:
> > On Tue, Sep 22, 2026 at 11:20:00AM +0530, Mukesh Kumar Chaurasiya (IBM) wrote:
> > > Verify that the __bug_table entry emitted by ARCH_WARN_ASM has a correct
> > > bug_addr displacement — i.e. the arch's trap label reference resolves to
> > > the trap instruction — by calling find_bug() with the exact virtual address
> > > of the trap, mirroring what the real trap handler does.
> > >
> > > To support all architectures, each arch that implements ARCH_WARN_ASM now
> > > defines ARCH_WARN_ASM_TRAP_LABEL, a string constant naming the local label
> > > at which the trap instruction is placed:
> > >
> > > x86 "1" (ud2 at label 1:)
> > > powerpc "1" (twi at label 1:)
> > > riscv "1" (ebreak at label 1:)
> > > arm64 "14471" (brk placed at 14471: by __BUG_ENTRY_END)
> > > s390 "0" (mc at label 0:)
> >
> > I'm not a fan of exposing such a low-level implementation detail out of
> > the architecture code, and I don't think we should expose this.
> >
> > What exactly are you trying to verify here, and why? Has there been
> > some _specific_ issue on powerpc that caused you to look at this?
> >
> > Mark.
>
> Hey Mark,
>
> During implementing ARCH_WARN_ASM for rust I broke the bug entry for
> powerpc so I wrote this to verify.

IIUC you mean you encoded the bug_entry::bug_addr field incorrectly?

Did that result in the entry *always* being wrong, or *sometimes* being
wrong?

AFAICT you should be able to use existing the LKDTM 'BUG' and 'WARNING'
tests for that sort of problem, no new code needed. They don't fit into
KUnit, but you should only need to run them when changing the way you
construct a bug_entry, so that doesn't seem like the end of the world.

> I sent it out mainly for ppc but few people wanted that if it needed
> it should be done for all archs. So separated this thing and sent it
> out as an RFC to check whether other archs want this or not.

Given the information provided so far, I don't think this is necessary.
I do not want this for arm64.

Mark.