From: FUJITA Tomonori <tomo@flapping.org>
To: gary@garyguo.net
Cc: mkchauras@gmail.com, maddy@linux.ibm.com, mpe@ellerman.id.au,
npiggin@gmail.com, chleroy@kernel.org, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
ojeda@kernel.org, boqun@kernel.org, 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,
linkmauve@linkmauve.fr, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
rust-for-linux@vger.kernel.org, tomo@flapping.org
Subject: Re: [PATCH V3] powerpc/bug: Add ARCH_WARN_ASM and refactor _EMIT_BUG_ENTRY for Rust support
Date: Thu, 10 Sep 2026 22:24:17 +0900 (JST) [thread overview]
Message-ID: <20260910.222417.2048885189565815846.tomo@flapping.org> (raw)
In-Reply-To: <DLBMFNHCKSJ6.1I36FDVEACEUF@garyguo.net>
On Thu, 10 Sep 2026 13:05:27 +0100
"Gary Guo" <gary@garyguo.net> wrote:
> On Thu Sep 10, 2026 at 11:08 AM BST, Mukesh Kumar Chaurasiya (IBM) wrote:
>> The Rust kernel infrastructure generates inline asm for WARN() via
>> ARCH_WARN_ASM(file, line, flags, size), expanding it through a C
>> preprocessor pass (generated_arch_warn_asm.rs.S) to produce an
>> arch-specific asm template string for use in Rust's core::arch macros.
>>
>> powerpc currently lacks ARCH_WARN_ASM and ARCH_WARN_REACHABLE, causing
>> Rust builds to fail on powerpc with
>> ```
>> error: no rules expected `ARCH_WARN_ASM`
>> --> /home/linkmauve/dev/linux/wii/rust/kernel/generated_arch_warn_asm.rs:1:28
>> |
>> 1 | ::kernel::concat_literals!(ARCH_WARN_ASM("{file}", "{line}", "{flags}", "{size}"))
>
> I think we probably want to catch this earlier by have something like
>
> #ifndef ARCH_WARN_ASM
> #error "ARCH_WARM_ASM is not defined"
> #endif
>
> in generated_arch_warn_asm.rs.S.
Good idea.
One thing needs to be fixed first. arm and loongarch do not define
ARCH_WARN_ASM. rust/kernel/bug.rs uses bindings::WARN_ON() on those
architectures, so it never includes generated_arch_warn_asm.rs. But
rust/Makefile still generates the file for them. With #error, their
builds would break.
I think we should add a condition to rust/Makefile to stop generating
the file for arm and loongarch. Then #error can be unconditional.
Does that sound reasonable? I can send patches.
>> arch/powerpc/include/asm/bug.h | 36 +++++++++++++++++++---------------
>> 1 file changed, 20 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
>> index 0db48977c70c..df2183c35945 100644
>> --- a/arch/powerpc/include/asm/bug.h
>> +++ b/arch/powerpc/include/asm/bug.h
>> @@ -32,34 +32,38 @@
>> #endif /* verbose */
>>
>> #else /* !__ASSEMBLER__ */
>> -/* _EMIT_BUG_ENTRY expects args %0,%1,%2,%3 to be FILE, LINE, flags and
>> - sizeof(struct bug_entry), respectively */
>> #ifdef CONFIG_DEBUG_BUGVERBOSE
>> -#define _EMIT_BUG_ENTRY \
>> - ".section __bug_table,\"aw\"\n" \
>> - "2: .4byte 1b - .\n" \
>> - " .4byte %0 - .\n" \
>> - " .short %1, %2\n" \
>> - ".org 2b+%3\n" \
>> - ".previous\n"
>> +#define _EMIT_BUG_ENTRY(label, file, line, flags) \
>> + ".section __bug_table,\"aw\"\n" \
>> + "2: .4byte " label "b - .\n" \
>
> "b" is part of the label. "1b" itself is a label and "1" is just an integer.
>
> If the code uses
>
> _EMIT_BUG_ENTRY(..)
> "1: ..."
>
> then the correct label would be "1f".
Agreed.
I think keeping the label fixed, as v2 did, would be fine too. x86,
arm64 and riscv all hardcode it. A comment that says the caller must
put the trap at 1: might be enough.
next prev parent reply other threads:[~2026-09-10 13:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 10:08 [PATCH V3] powerpc/bug: Add ARCH_WARN_ASM and refactor _EMIT_BUG_ENTRY for Rust support Mukesh Kumar Chaurasiya (IBM)
2026-09-10 12:05 ` Gary Guo
2026-09-10 13:24 ` FUJITA Tomonori [this message]
2026-09-11 5:21 ` Mukesh Kumar Chaurasiya
2026-09-11 5:16 ` Mukesh Kumar Chaurasiya
2026-09-10 15:08 ` Christophe Leroy (CS GROUP)
2026-09-11 5:24 ` 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=20260910.222417.2048885189565815846.tomo@flapping.org \
--to=tomo@flapping.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=alex@ghiti.fr \
--cc=aliceryhl@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=chleroy@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=linkmauve@linkmauve.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lossin@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mkchauras@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
/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