arch/arm64/include/asm/asm-bug.h | 33 ++++- arch/riscv/include/asm/bug.h | 37 +++--- arch/x86/include/asm/bug.h | 56 ++++---- rust/Makefile | 8 ++ rust/helpers/bug.c | 5 + rust/kernel/.gitignore | 2 + rust/kernel/bug.rs | 125 ++++++++++++++++++ rust/kernel/generated_arch_reachable_asm.rs.S | 7 + rust/kernel/generated_arch_warn_asm.rs.S | 7 + rust/kernel/lib.rs | 1 + 10 files changed, 234 insertions(+), 47 deletions(-) create mode 100644 rust/kernel/bug.rs create mode 100644 rust/kernel/generated_arch_reachable_asm.rs.S create mode 100644 rust/kernel/generated_arch_warn_asm.rs.S
This patchset adds warn_on macro with the bug/warn abstraction that
utilizes the kernel's BUG/WARN feature via assembly.
Currently, Rust code simply wraps BUG() macro; however the approach
doesn't provide the proper debug information. For example, I added
bindings::BUG() to rnull's init method and got the following output:
# insmod /root/rnull_mod.ko
rnull_mod: Rust null_blk loaded
------------[ cut here ]------------
kernel BUG at rust/helpers/bug.c:7!
Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 0 PID: 31 Comm: insmod Not tainted 6.14.0-rc1+ #103
RIP: 0010:rust_helper_BUG+0x8/0x10
(snip)
The kernel's BUG/WARN feature (lib/bug.c) can only be used from
assembly. Rust code needs to directly execute the same assembly code
used on the C side. To avoid duplicating the assembly code, this
approach follows the same strategy as the static branch code: it
generates the assembly code for Rust using the C preprocessor at
compile time.
The 1st to 3th patches export the BUG/WARN assembly code for Rust on
x86, RISC-V, and ARM64 architecture, with no functional changes on the
C side. They have already been acked by the maintainers of their
respective architectures.
No change for ARM and LoongArch; they still use the current approach;
just wrapping C's macro.
UML doesn't use the assembly BUG/WARN feature; just wrapping generic
BUG/WARN functions implemented in C works.
The last patch adds warn_on implementation on the top of the
abstraction. To make the patchset easier to review, the remaining
features such as bug() are not included in this patchset. These
features will be added after this patchset is merged.
This has been tested on x86, ARM64, and RISC-V (QEMU), with only a
compile test performed for LoongArch, ARM, and UML.
v6:
- improved SAFETY comments
v5: https://lore.kernel.org/lkml/20250409065802.136971-1-fujita.tomonori@gmail.com/
- fix indentation in the macro
- use $crate::ffi::c_char instead ::kernel::ffi::c_uchar
- add support for building on arm32
v4: https://lore.kernel.org/lkml/20250305110814.272792-1-fujita.tomonori@gmail.com/
- added Acked-by tag to the RISC-V and ARM64 asm change
- simplify the asm code
- use the cfgs on the macro rather in its expansion
- use a const fn for bugflag_taint over macro
- dropped LoongArch assembly change
- dropped warn_on_once; make the patch easier to review
v3: https://lore.kernel.org/lkml/20250213135759.190006-1-fujita.tomonori@gmail.com/
- rebased on rust-next
- use ANNOTATE_REACHABLE macro (replaced ASM_REACHABLE)
- added Acked-by tag to the x86 change
v2: https://lore.kernel.org/lkml/20241218062009.2402650-1-fujita.tomonori@gmail.com/
- remove target_arch cfg by using asm comment
- clean up the changes to loongarch asm
v1: https://lore.kernel.org/lkml/20241210001802.228725-1-fujita.tomonori@gmail.com/
FUJITA Tomonori (4):
x86/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with
Rust
riscv/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with
Rust
arm64/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with
Rust
rust: Add warn_on macro
arch/arm64/include/asm/asm-bug.h | 33 ++++-
arch/riscv/include/asm/bug.h | 37 +++---
arch/x86/include/asm/bug.h | 56 ++++----
rust/Makefile | 8 ++
rust/helpers/bug.c | 5 +
rust/kernel/.gitignore | 2 +
rust/kernel/bug.rs | 125 ++++++++++++++++++
rust/kernel/generated_arch_reachable_asm.rs.S | 7 +
rust/kernel/generated_arch_warn_asm.rs.S | 7 +
rust/kernel/lib.rs | 1 +
10 files changed, 234 insertions(+), 47 deletions(-)
create mode 100644 rust/kernel/bug.rs
create mode 100644 rust/kernel/generated_arch_reachable_asm.rs.S
create mode 100644 rust/kernel/generated_arch_warn_asm.rs.S
base-commit: 9d7a0577c9db35c4cc52db90bc415ea248446472
--
2.43.0
On Fri, May 2, 2025 at 11:46 AM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> This patchset adds warn_on macro with the bug/warn abstraction that
> utilizes the kernel's BUG/WARN feature via assembly.
Ok, let's move forward with this.
I took a look at the first three patches and compared the expanded
output for the existing macros, to make sure we (hopefully) don't
break anything else.
It seems OK, I only noticed a removed newline. Was that intentional?
There was also a bad parameter name, but that was not hurting anything
since it was unused.
(For the x86 one could be closer removing a couple spaces, but it
should not matter and other x86 files format it that way, so I didn't
change it. I also noticed unexpected spaces used for aligning the
macro, but it turned out it was in the original already, so I left it
also unchanged.)
Then I found a few more bits on the last patch.
Tomo, could you please double-check you are OK with all the changes,
and please run the tests you did back then on `rust-next` again for
all arches, given it has been a while since you posted it (plus I did
a few changes on top, after all)? I would appreciate it, thanks in
advance!
To be clear, I didn't re-check every single thing/combination, but
hopefully what I caught helps. Since there are no users anyway (of the
last patch) right now, it should be fairly safe.
Applied to `rust-next` -- thanks everyone!
[ Fixed typo in macro parameter name. - Miguel ]
[ Remove ending newline in `ARCH_WARN_ASM` content to be closer to the
original. - Miguel ]
[ Avoid evaluating the condition twice (a good idea in general,
but it also matches the C side). Simplify with `as_char_ptr()`
to avoid a cast. Cast to `ffi` integer types for
`warn_slowpath_fmt`. Avoid cast for `null()`. - Miguel ]
Cheers,
Miguel
On Wed, 23 Jul 2025 02:48:20 +0200 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: >> This patchset adds warn_on macro with the bug/warn abstraction that >> utilizes the kernel's BUG/WARN feature via assembly. > > Ok, let's move forward with this. > > I took a look at the first three patches and compared the expanded > output for the existing macros, to make sure we (hopefully) don't > break anything else. Thanks a lot! > It seems OK, I only noticed a removed newline. Was that intentional? The patch for arm64? I tried to minimize changes to the original code so not intentional. > There was also a bad parameter name, but that was not hurting anything > since it was unused. > > (For the x86 one could be closer removing a couple spaces, but it > should not matter and other x86 files format it that way, so I didn't > change it. I also noticed unexpected spaces used for aligning the > macro, but it turned out it was in the original already, so I left it > also unchanged.) Yeah, I followed the original code style. > Then I found a few more bits on the last patch. > > Tomo, could you please double-check you are OK with all the changes, > and please run the tests you did back then on `rust-next` again for > all arches, given it has been a while since you posted it (plus I did > a few changes on top, after all)? I would appreciate it, thanks in > advance! I've just tested rust-next. Looks like all arches (x86, riscv, and arm64) works as expected. > To be clear, I didn't re-check every single thing/combination, but > hopefully what I caught helps. Since there are no users anyway (of the > last patch) right now, it should be fairly safe. > > Applied to `rust-next` -- thanks everyone! > > [ Fixed typo in macro parameter name. - Miguel ] > > [ Remove ending newline in `ARCH_WARN_ASM` content to be closer to the > original. - Miguel ] > > [ Avoid evaluating the condition twice (a good idea in general, > but it also matches the C side). Simplify with `as_char_ptr()` > to avoid a cast. Cast to `ffi` integer types for > `warn_slowpath_fmt`. Avoid cast for `null()`. - Miguel ] > All the changes look good. Thanks!
On Wed, Jul 23, 2025 at 8:21 AM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> The patch for arm64? I tried to minimize changes to the original code
> so not intentional.
The riscv one, i.e. from the range diff:
@@ arch/riscv/include/asm/bug.h: typedef u32 bug_insn_t;
"2:\n\t" \
- __BUG_ENTRY "\n\t" \
- ".org 2b + %3\n\t" \
-- ".popsection" \
+ __BUG_ENTRY(file, line, flags) "\n\t" \
+ ".org 2b + " size "\n\t" \
-+ ".popsection\n" \
+ ".popsection" \
+
+#define __BUG_FLAGS(flags) \
+do { \
If you look into the `.popsection` line, your patch adds a newline,
but I guess it was not intentional. In x86 there is a newline after
the directive, but there we have `extra` afterwards.
(I noticed since I went to expand the macros in a dummy file, given it
can be something tricky to spot differences in the normal diff, but it
is visible in the normal diff.)
> Yeah, I followed the original code style.
And here I meant (i.e. the first part of that paragraph) that:
- "\t.org 2b+%c1\n" \
now generated those two spaces around it:
+ "\t.org 2b + " size "\n" \
> I've just tested rust-next. Looks like all arches (x86, riscv, and
> arm64) works as expected.
Thanks a lot!
Cheers,
Miguel
On Wed, 23 Jul 2025 11:52:04 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>> The patch for arm64? I tried to minimize changes to the original code
>> so not intentional.
>
> The riscv one, i.e. from the range diff:
>
> @@ arch/riscv/include/asm/bug.h: typedef u32 bug_insn_t;
> "2:\n\t" \
> - __BUG_ENTRY "\n\t" \
> - ".org 2b + %3\n\t" \
> -- ".popsection" \
> + __BUG_ENTRY(file, line, flags) "\n\t" \
> + ".org 2b + " size "\n\t" \
> -+ ".popsection\n" \
> + ".popsection" \
> +
> +#define __BUG_FLAGS(flags) \
> +do { \
>
> If you look into the `.popsection` line, your patch adds a newline,
> but I guess it was not intentional. In x86 there is a newline after
> the directive, but there we have `extra` afterwards.
Oops, indeed it's not intentional.
> (I noticed since I went to expand the macros in a dummy file, given it
> can be something tricky to spot differences in the normal diff, but it
> is visible in the normal diff.)
>
>> Yeah, I followed the original code style.
>
> And here I meant (i.e. the first part of that paragraph) that:
>
> - "\t.org 2b+%c1\n" \
>
> now generated those two spaces around it:
>
> + "\t.org 2b + " size "\n" \
>
Ah, not intentional again.
On Fri, May 2, 2025 at 11:46 AM FUJITA Tomonori <fujita.tomonori@gmail.com> wrote: > > This patchset adds warn_on macro with the bug/warn abstraction that > utilizes the kernel's BUG/WARN feature via assembly. This passed my usual tests -- I will take a better look and pick it early next cycle. Cheers, Miguel
On Thu, 5 Jun 2025 03:56:31 +0200 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > On Fri, May 2, 2025 at 11:46 AM FUJITA Tomonori > <fujita.tomonori@gmail.com> wrote: >> >> This patchset adds warn_on macro with the bug/warn abstraction that >> utilizes the kernel's BUG/WARN feature via assembly. > > This passed my usual tests -- I will take a better look and pick it > early next cycle. Perfect, thank you so much!
© 2016 - 2025 Red Hat, Inc.