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.
next prev parent reply other threads:[~2026-09-24 12:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 5:50 Mukesh Kumar Chaurasiya (IBM)
2026-09-22 6:47 ` Peter Zijlstra
2026-09-23 6:28 ` Mukesh Kumar Chaurasiya
2026-09-24 11:15 ` Peter Zijlstra
2026-09-24 12:46 ` Mark Rutland [this message]
2026-09-24 12:52 ` Peter Zijlstra
2026-09-24 13:05 ` Mark Rutland
2026-09-24 15:13 ` Heiko Carstens
2026-09-24 12:31 ` Mark Rutland
2026-09-24 13:00 ` Christophe Leroy (CS GROUP)
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®