From: Mark Rutland <mark.rutland@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mukesh Kumar Chaurasiya <mkchauras@gmail.com>,
catalin.marinas@arm.com, will@kernel.org, maddy@linux.ibm.com,
mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org,
ritesh.list@gmail.com, sshegde@linux.ibm.com, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com,
borntraeger@linux.ibm.com, svens@linux.ibm.com, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, ojeda@kernel.org,
boqun@kernel.org, gary@garyguo.net, bjorn3_gh@protonmail.com,
lossin@kernel.org, a.hindborg@kernel.org, aliceryhl@google.com,
tmgross@umich.edu, dakr@kernel.org, daniel.almeida@collabora.com,
tamird@kernel.org, acourbot@nvidia.com, work@onurozkan.dev,
nathan@kernel.org, ndesaulniers@google.com, morbo@google.com,
justinstitt@google.com, jszhang@kernel.org, japo@linux.ibm.com,
jpoimboe@kernel.org, seanjc@google.com, pmladek@suse.com,
thuth@redhat.com, ynorov@nvidia.com, joelagnelf@nvidia.com,
david@davidgow.net, fujita.tomonori@gmail.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
rust-for-linux@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [RFC] rust: kernel: Add KUnit tests for ARCH_WARN_ASM bug table emission
Date: Thu, 24 Sep 2026 13:46:59 +0100 [thread overview]
Message-ID: <arUbw_TIA0Uj7oXT@J2N7QTR9R3> (raw)
In-Reply-To: <20260924111557.GP1837346@noisy.programming.kicks-ass.net>
On Thu, Sep 24, 2026 at 01:15:57PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 23, 2026 at 11:58:13AM +0530, Mukesh Kumar Chaurasiya wrote:
> > On Tue, Sep 22, 2026 at 08:47:35AM +0200, Peter Zijlstra 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:)
> > > >
> > > > The label is used consistently: in ARCH_WARN_ASM itself, in the
> > > > bug_addr back-reference inside __BUG_ENTRY / _EMIT_BUG_ENTRY,
> > > Not really a fan of that. And I can't really tell what you're doing with
> > > it either. The kunit is in Rust and thus unreadable :-(
> > >
> > > I would rather you fix up is_valid_bugaddr(), some architectures seem to
> > > have an always true stub because of the callchains always being from the
> > > break instruction.
> >
> > Hey Peter,
> >
> > thanks for the suggestion. I will fix up the is_valid_bugaddr for
> > powerpc. I am not very good with other archs asm but i can do it for
> > ppc32 and ppc64.
>
> Untested thingies for arm64 and s390x.
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 914282016069..3d8a969eab5f 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -987,14 +987,13 @@ void do_serror(struct pt_regs *regs, unsigned long esr)
> #ifdef CONFIG_GENERIC_BUG
> int is_valid_bugaddr(unsigned long addr)
> {
> - /*
> - * bug_brk_handler() only called for BRK #BUG_BRK_IMM.
> - * So the answer is trivial -- any spurious instances with no
> - * bug table entry will be rejected by report_bug() and passed
> - * back to the debug-monitors code and handled as a fatal
> - * unexpected debug exception.
> - */
> - return 1;
> + u32 insn;
> +
> + if (aarch64_insn_read((u32 *)addr, &insn))
> + return 0;
> +
> + /* Match ASM_BUG_FLAGS() / BUG() instructions. */
> + return insn == (0xd4200000 | (BUG_BRK_IMM << 5));
> }
> #endif
What problem is this trying to solve?
Mukesh's original patch seems to be trying to check whether we compiled
things correctly (such that the bug_table entry points at the expected
insturction), and I don't think that warrants a runtime check, but (as
per my reply to him) I don't understand why that's a thing to check in
the first place.
On arm64 we only call is_valid_bugaddr() under do_el1_brk64() ->
call_el1_break_hook() -> bug_brk_handler(). We only call
bug_brk_handler() when HW has taken a BRK exception with the BUG_BRK_IMM
immediate, and that can only be triggered by executing the right
instruction (BRK #BUG_BRK_IMM), which we ONLY use for BUG(). and WARN().
So I don't see why any change is necessary here.
If the HW has somehow taken a BRK exception from any other instruction
(which would presumably be a HW bug), there won't be a bug_table entry,
and so __report_bug() will fail to find an entry, and will return
BUG_TRAP_TYPE_NONE, same as for the !is_valid_bugaddr() case.
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mukesh Kumar Chaurasiya <mkchauras@gmail.com>,
catalin.marinas@arm.com, will@kernel.org, maddy@linux.ibm.com,
mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org,
ritesh.list@gmail.com, sshegde@linux.ibm.com, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com,
borntraeger@linux.ibm.com, svens@linux.ibm.com, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, ojeda@kernel.org,
boqun@kernel.org, gary@garyguo.net, bjorn3_gh@protonmail.com,
lossin@kernel.org, a.hindborg@kernel.org, aliceryhl@google.com,
tmgross@umich.edu, dakr@kernel.org, daniel.almeida@collabora.com,
tamird@kernel.org, acourbot@nvidia.com, work@onurozkan.dev,
nathan@kernel.org, ndesaulniers@google.com, morbo@google.com,
justinstitt@google.com, jszhang@kernel.org, japo@linux.ibm.com,
jpoimboe@kernel.org, seanjc@google.com, pmladek@suse.com,
thuth@redhat.com, ynorov@nvidia.com, joelagnelf@nvidia.com,
david@davidgow.net, fujita.tomonori@gmail.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
rust-for-linux@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [RFC] rust: kernel: Add KUnit tests for ARCH_WARN_ASM bug table emission
Date: Thu, 24 Sep 2026 13:46:59 +0100 [thread overview]
Message-ID: <arUbw_TIA0Uj7oXT@J2N7QTR9R3> (raw)
In-Reply-To: <20260924111557.GP1837346@noisy.programming.kicks-ass.net>
On Thu, Sep 24, 2026 at 01:15:57PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 23, 2026 at 11:58:13AM +0530, Mukesh Kumar Chaurasiya wrote:
> > On Tue, Sep 22, 2026 at 08:47:35AM +0200, Peter Zijlstra 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:)
> > > >
> > > > The label is used consistently: in ARCH_WARN_ASM itself, in the
> > > > bug_addr back-reference inside __BUG_ENTRY / _EMIT_BUG_ENTRY,
> > > Not really a fan of that. And I can't really tell what you're doing with
> > > it either. The kunit is in Rust and thus unreadable :-(
> > >
> > > I would rather you fix up is_valid_bugaddr(), some architectures seem to
> > > have an always true stub because of the callchains always being from the
> > > break instruction.
> >
> > Hey Peter,
> >
> > thanks for the suggestion. I will fix up the is_valid_bugaddr for
> > powerpc. I am not very good with other archs asm but i can do it for
> > ppc32 and ppc64.
>
> Untested thingies for arm64 and s390x.
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 914282016069..3d8a969eab5f 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -987,14 +987,13 @@ void do_serror(struct pt_regs *regs, unsigned long esr)
> #ifdef CONFIG_GENERIC_BUG
> int is_valid_bugaddr(unsigned long addr)
> {
> - /*
> - * bug_brk_handler() only called for BRK #BUG_BRK_IMM.
> - * So the answer is trivial -- any spurious instances with no
> - * bug table entry will be rejected by report_bug() and passed
> - * back to the debug-monitors code and handled as a fatal
> - * unexpected debug exception.
> - */
> - return 1;
> + u32 insn;
> +
> + if (aarch64_insn_read((u32 *)addr, &insn))
> + return 0;
> +
> + /* Match ASM_BUG_FLAGS() / BUG() instructions. */
> + return insn == (0xd4200000 | (BUG_BRK_IMM << 5));
> }
> #endif
What problem is this trying to solve?
Mukesh's original patch seems to be trying to check whether we compiled
things correctly (such that the bug_table entry points at the expected
insturction), and I don't think that warrants a runtime check, but (as
per my reply to him) I don't understand why that's a thing to check in
the first place.
On arm64 we only call is_valid_bugaddr() under do_el1_brk64() ->
call_el1_break_hook() -> bug_brk_handler(). We only call
bug_brk_handler() when HW has taken a BRK exception with the BUG_BRK_IMM
immediate, and that can only be triggered by executing the right
instruction (BRK #BUG_BRK_IMM), which we ONLY use for BUG(). and WARN().
So I don't see why any change is necessary here.
If the HW has somehow taken a BRK exception from any other instruction
(which would presumably be a HW bug), there won't be a bug_table entry,
and so __report_bug() will fail to find an entry, and will return
BUG_TRAP_TYPE_NONE, same as for the !is_valid_bugaddr() case.
Mark.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-09-24 12:47 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 5:50 [RFC] rust: kernel: Add KUnit tests for ARCH_WARN_ASM bug table emission Mukesh Kumar Chaurasiya (IBM)
2026-09-22 5:50 ` Mukesh Kumar Chaurasiya (IBM)
2026-09-22 6:47 ` Peter Zijlstra
2026-09-22 6:47 ` Peter Zijlstra
2026-09-23 6:28 ` Mukesh Kumar Chaurasiya
2026-09-23 6:28 ` Mukesh Kumar Chaurasiya
2026-09-24 11:15 ` Peter Zijlstra
2026-09-24 11:15 ` Peter Zijlstra
2026-09-24 12:46 ` Mark Rutland [this message]
2026-09-24 12:46 ` Mark Rutland
2026-09-24 12:52 ` Peter Zijlstra
2026-09-24 12:52 ` Peter Zijlstra
2026-09-24 13:05 ` Mark Rutland
2026-09-24 13:05 ` Mark Rutland
2026-09-25 6:32 ` Mukesh Kumar Chaurasiya
2026-09-25 6:32 ` Mukesh Kumar Chaurasiya
2026-09-24 15:13 ` Heiko Carstens
2026-09-24 15:13 ` Heiko Carstens
2026-09-25 6:36 ` Mukesh Kumar Chaurasiya
2026-09-25 6:36 ` Mukesh Kumar Chaurasiya
2026-09-25 8:44 ` Heiko Carstens
2026-09-25 8:44 ` Heiko Carstens
2026-09-25 6:38 ` Mukesh Kumar Chaurasiya
2026-09-25 6:38 ` Mukesh Kumar Chaurasiya
2026-09-24 12:31 ` Mark Rutland
2026-09-24 12:31 ` Mark Rutland
2026-09-25 6:21 ` Mukesh Kumar Chaurasiya
2026-09-25 6:21 ` Mukesh Kumar Chaurasiya
2026-09-25 8:06 ` Mark Rutland
2026-09-25 8:06 ` Mark Rutland
2026-09-24 13:00 ` Christophe Leroy (CS GROUP)
2026-09-24 13:00 ` Christophe Leroy (CS GROUP)
2026-09-25 6:34 ` Mukesh Kumar Chaurasiya
2026-09-25 6:34 ` Mukesh Kumar Chaurasiya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arUbw_TIA0Uj7oXT@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=agordeev@linux.ibm.com \
--cc=alex@ghiti.fr \
--cc=aliceryhl@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chleroy@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@davidgow.net \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=japo@linux.ibm.com \
--cc=joelagnelf@nvidia.com \
--cc=jpoimboe@kernel.org \
--cc=jszhang@kernel.org \
--cc=justinstitt@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=llvm@lists.linux.dev \
--cc=lossin@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mingo@redhat.com \
--cc=mkchauras@gmail.com \
--cc=morbo@google.com \
--cc=mpe@ellerman.id.au \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=npiggin@gmail.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=pmladek@suse.com \
--cc=ritesh.list@gmail.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=seanjc@google.com \
--cc=sshegde@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=tamird@kernel.org \
--cc=tglx@kernel.org \
--cc=thuth@redhat.com \
--cc=tmgross@umich.edu \
--cc=will@kernel.org \
--cc=work@onurozkan.dev \
--cc=x86@kernel.org \
--cc=ynorov@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.