From: Alice Ryhl <aliceryhl@google.com>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
x86@kernel.org, linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, peterz@infradead.org,
hpa@zytor.com, paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, catalin.marinas@arm.com, will@kernel.org,
chenhuacai@kernel.org, kernel@xen0n.name,
tangyouling@loongson.cn, hejinyang@loongson.cn,
yangtiezhu@loongson.cn, ojeda@kernel.org, alex.gaynor@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@kernel.org, tmgross@umich.edu
Subject: Re: [PATCH v3 5/5] rust: Add warn_on and warn_on_once
Date: Wed, 5 Mar 2025 10:36:22 +0000 [thread overview]
Message-ID: <Z8gpJsQlkjAQ0EwU@google.com> (raw)
In-Reply-To: <20250305.192403.996225631653343672.fujita.tomonori@gmail.com>
On Wed, Mar 05, 2025 at 07:24:03PM +0900, FUJITA Tomonori wrote:
> On Wed, 5 Mar 2025 08:42:57 +0000
> Alice Ryhl <aliceryhl@google.com> wrote:
>
> > On Thu, Feb 13, 2025 at 10:57:59PM +0900, FUJITA Tomonori wrote:
> >> Add warn_on and warn_on_once macros. Wrapping the C's WARN_* and BUG_*
> >> macros doesn't work so this uses the assembly code exported by the C
> >> side via ARCH_WARN_ASM macro. Like the static branch code, this
> >> generates the assembly code for rust at compile time by using the C
> >> preprocessor.
> >>
> >> file()! macro doesn't work for the Rust inline assembly in the same
> >> way as __FILE__ for the C inline assembly. So the code to handle a
> >> file name is different from the C assembly code (similar to the
> >> arm64/loongarch assembly).
> >
> > Nit: Should be file!() not file()!.
>
> Ops, thanks.
>
> Actually, the above comment is obsolete. With your solution in the
> previous mail, I can remove the asm code for the file name. I'll
> remove the comment.
>
>
> >> diff --git a/rust/kernel/.gitignore b/rust/kernel/.gitignore
> >> index 6ba39a178f30..f1d7f4225332 100644
> >> --- a/rust/kernel/.gitignore
> >> +++ b/rust/kernel/.gitignore
> >> @@ -1,3 +1,5 @@
> >> # SPDX-License-Identifier: GPL-2.0
> >>
> >> /generated_arch_static_branch_asm.rs
> >> +/generated_arch_warn_asm.rs
> >> +/generated_arch_reachable_asm.rs
> >> \ No newline at end of file
> >
> > There should be a newline.
>
> Ah, I'll fix.
>
> >> +++ b/rust/kernel/bug.rs
> >> @@ -0,0 +1,100 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +
> >> +// Copyright (C) 2024 FUJITA Tomonori
> >
> > 2025?
>
> I'll add.
>
> >> +#[macro_export]
> >> +#[doc(hidden)]
> >> +#[cfg(all(CONFIG_BUG, not(CONFIG_UML)))]
> >> +macro_rules! warn_flags {
> >> + ($flags:expr) => {
> >> + const FLAGS: u32 = $crate::bindings::BUGFLAG_WARNING | $flags;
> >> + // SAFETY: Just an FFI call.
> >> + #[cfg(CONFIG_DEBUG_BUGVERBOSE)]
> >> + unsafe {
> >> + $crate::asm!(concat!(
> >> + "/* {size} */",
> >> + ".pushsection .rodata.str1.1, \"aMS\",@progbits, 1\n",
> >> + "111:\t .string ", "\"", file!(), "\"\n",
> >> + ".popsection\n",
> >> + include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_warn_asm.rs")),
> >> + include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_reachable_asm.rs")));
> >> + line = const line!(),
> >> + flags = const FLAGS,
> >> + size = const ::core::mem::size_of::<$crate::bindings::bug_entry>(),
> >> + );
> >> + }
> >> + // SAFETY: Just an FFI call.
> >> + #[cfg(not(CONFIG_DEBUG_BUGVERBOSE))]
> >> + unsafe {
> >> + $crate::asm!(
> >> + concat!(
> >> + "/* {size} */",
> >> + include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_warn_asm.rs")),
> >> + include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_reachable_asm.rs")));
> >> + flags = const FLAGS,
> >> + size = const ::core::mem::size_of::<$crate::bindings::bug_entry>(),
> >> + );
> >> + }
> >
> > I generally prefer to have the cfgs on the macro rather in its
> > expansion. That avoids emitting a lot of code that is not actually used.
>
> You prefer the following?
>
> #[cfg(all(CONFIG_BUG, CONFIG_DEBUG_BUGVERBOSE, not(CONFIG_UML)))]
> macro_rules! warn_flags {
> ...
> }
>
> #[cfg(all(CONFIG_BUG, not(CONFIG_DEBUG_BUGVERBOSE), not(CONFIG_UML)))]
> macro_rules! warn_flags {
> ...
> }
In this case it probably reads better as
#[cfg(all(CONFIG_BUG, not(CONFIG_UML)))]
#[cfg(CONFIG_DEBUG_BUGVERBOSE)]
macro_rules! warn_flags {
...
}
#[cfg(all(CONFIG_BUG, not(CONFIG_UML)))]
#[cfg(not(CONFIG_DEBUG_BUGVERBOSE))]
macro_rules! warn_flags {
...
}
but yes.
> >> +#[doc(hidden)]
> >> +#[macro_export]
> >> +macro_rules! bugflag_taint {
> >> + ($taint:expr) => {
> >> + $taint << 8
> >> + };
> >> +}
> >
> > This could just be a const fn.
>
> Yeah, would a const fn be preferable?
Yes, I think a constant or const fn is preferable over a macro whenever
possible.
> >> +/// Report a warning only once.
> >> +#[macro_export]
> >> +macro_rules! warn_on_once {
> >> + ($cond:expr) => {
> >> + if $cond {
> >> + $crate::warn_flags!(
> >> + $crate::bindings::BUGFLAG_ONCE
> >> + | $crate::bugflag_taint!($crate::bindings::TAINT_WARN)
> >
> > Or maybe a constant?
> >
> > const WARN_ON_ONCE_FLAGS: u32 = bindings::BUGFLAG_ONCE | (bindings::TAINT_WARN << 8);
>
> Ok, but you prefer "<< 8" than using const fn bugflag_taint()?
I'm also happy with
const WARN_ON_ONCE_FLAGS: u32 = bindings::BUGFLAG_ONCE | bugflag_taint(bindings::TAINT_WARN);
Up to you.
Alice
next prev parent reply other threads:[~2025-03-05 11:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <yy_ESUuchCjlaGIJHzCPAcP_d9ucSD0CGXaoZNNkY7BmN5Ch1J8avsA9QpKO5LkTjlGpu99jl8NrFl5NFSQXuw==@protonmail.internalid>
2025-02-13 13:57 ` [PATCH v3 0/5] rust: Add bug/warn abstractions FUJITA Tomonori
2025-02-13 13:57 ` [PATCH v3 1/5] x86/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with Rust FUJITA Tomonori
2025-02-13 13:57 ` [PATCH v3 2/5] riscv/bug: " FUJITA Tomonori
2025-02-28 10:13 ` Alexandre Ghiti
2025-02-13 13:57 ` [PATCH v3 3/5] arm64/bug: " FUJITA Tomonori
2025-02-26 19:27 ` Catalin Marinas
2025-02-27 7:01 ` FUJITA Tomonori
2025-02-13 13:57 ` [PATCH v3 4/5] loongarch/bug: " FUJITA Tomonori
2025-02-13 13:57 ` [PATCH v3 5/5] rust: Add warn_on and warn_on_once FUJITA Tomonori
2025-03-03 13:33 ` Alice Ryhl
2025-03-05 5:13 ` FUJITA Tomonori
2025-03-05 8:42 ` Alice Ryhl
2025-03-05 10:24 ` FUJITA Tomonori
2025-03-05 10:36 ` Alice Ryhl [this message]
2025-02-26 19:39 ` [PATCH v3 0/5] rust: Add bug/warn abstractions Andreas Hindborg
2025-02-27 6:54 ` FUJITA Tomonori
2025-02-27 8:28 ` Andreas Hindborg
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=Z8gpJsQlkjAQ0EwU@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=hejinyang@loongson.cn \
--cc=hpa@zytor.com \
--cc=kernel@xen0n.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=loongarch@lists.linux.dev \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tangyouling@loongson.cn \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yangtiezhu@loongson.cn \
/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;
as well as URLs for NNTP newsgroup(s).