* [PATCH v2 03/33] rust: kbuild: remove unneeded old `allow`s for generated layout tests
From: Miguel Ojeda @ 2026-04-05 23:52 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
The issue that required `allow`s for `cfg(test)` code generated by
`bindgen` for layout testing was fixed back in `bindgen` 0.60.0 [1],
so it could have been removed even before the version bump, but it does
not hurt.
Thus remove it now.
Link: https://github.com/rust-lang/rust-bindgen/pull/2203 [1]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
rust/bindings/lib.rs | 4 ----
rust/uapi/lib.rs | 4 ----
2 files changed, 8 deletions(-)
diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs
index 19f57c5b2fa2..e18c160dad17 100644
--- a/rust/bindings/lib.rs
+++ b/rust/bindings/lib.rs
@@ -9,10 +9,6 @@
//! using this crate.
#![no_std]
-// See <https://github.com/rust-lang/rust-bindgen/issues/1651>.
-#![cfg_attr(test, allow(deref_nullptr))]
-#![cfg_attr(test, allow(unaligned_references))]
-#![cfg_attr(test, allow(unsafe_op_in_unsafe_fn))]
#![allow(
clippy::all,
missing_docs,
diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs
index 1d5fd9efb93e..821e286e0daa 100644
--- a/rust/uapi/lib.rs
+++ b/rust/uapi/lib.rs
@@ -8,10 +8,6 @@
//! userspace APIs.
#![no_std]
-// See <https://github.com/rust-lang/rust-bindgen/issues/1651>.
-#![cfg_attr(test, allow(deref_nullptr))]
-#![cfg_attr(test, allow(unaligned_references))]
-#![cfg_attr(test, allow(unsafe_op_in_unsafe_fn))]
#![allow(
clippy::all,
clippy::cast_lossless,
--
2.53.0
^ permalink raw reply related
* [PATCH v2 02/33] rust: kbuild: remove "`try` keyword" workaround for `bindgen` < 0.59.2
From: Miguel Ojeda @ 2026-04-05 23:52 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
There is a workaround that has not been needed, even already after commit
08ab786556ff ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt.
Thus remove it.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
rust/bindgen_parameters | 4 ----
1 file changed, 4 deletions(-)
diff --git a/rust/bindgen_parameters b/rust/bindgen_parameters
index fd2fd1c3cb9a..112ec197ef0a 100644
--- a/rust/bindgen_parameters
+++ b/rust/bindgen_parameters
@@ -15,10 +15,6 @@
--opaque-type x86_msi_data
--opaque-type x86_msi_addr_lo
-# `try` is a reserved keyword since Rust 2018; solved in `bindgen` v0.59.2,
-# commit 2aed6b021680 ("context: Escape the try keyword properly").
---opaque-type kunit_try_catch
-
# If SMP is disabled, `arch_spinlock_t` is defined as a ZST which triggers a Rust
# warning. We don't need to peek into it anyway.
--opaque-type spinlock
--
2.53.0
^ permalink raw reply related
* [PATCH v2 01/33] rust: kbuild: remove `--remap-path-prefix` workarounds
From: Miguel Ojeda @ 2026-04-05 23:52 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
Commit 8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix
to make paths relative"") removed `--remap-path-prefix` from the build
system, so the workarounds are not needed anymore.
Thus remove them.
Note that the flag has landed again in parallel in this cycle in
commit dda135077ecc ("rust: build: remap path to avoid absolute path"),
together with `--remap-path-scope=macro` [1]. However, they are gated on
`rustc-option-yn, --remap-path-scope=macro`, which means they are both
only passed starting with Rust 1.95.0 [2]:
`--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option`
to detect its presence. This feature has been available as
`-Zremap-path-scope` for all versions that we support; however due to
bugs in the Rust compiler, it does not work reliably until 1.94. I opted
to not enable it for 1.94 as it's just a single version that we missed.
In turn, that means the workarounds removed here should not be needed
again (even with the flag added again above), since:
- `rustdoc` now recognizes the `--remap-path-prefix` flag since Rust
1.81.0 [3] (even if it is still an unstable feature [4]).
- The Internal Compiler Error [5] that the comment mentions was fixed in
Rust 1.87.0 [6]. We tested that was the case in a previous version
of this series by making the workaround conditional [7][8].
...which are both older versions than Rust 1.95.0.
We will still need to skip `--remap-path-scope` for `rustdoc` though,
since `rustdoc` does not support that one yet [4].
Link: https://github.com/rust-lang/rust/issues/111540 [1]
Link: https://github.com/rust-lang/rust/pull/147611 [2]
Link: https://github.com/rust-lang/rust/pull/107099 [3]
Link: https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--remap-path-prefix-remap-source-code-paths-in-output [4]
Link: https://github.com/rust-lang/rust/issues/138520 [5]
Link: https://github.com/rust-lang/rust/pull/138556 [6]
Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-9-ojeda@kernel.org/ [7]
Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-10-ojeda@kernel.org/ [8]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
rust/Makefile | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/rust/Makefile b/rust/Makefile
index 96cd7d8e6ee9..16ea720e0a8e 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -145,14 +145,10 @@ rustdoc_modifiers_workaround := $(if $(call rustc-min-version,108800),-Cunsafe-a
# Similarly, for doctests (https://github.com/rust-lang/rust/issues/146465).
doctests_modifiers_workaround := $(rustdoc_modifiers_workaround)$(if $(call rustc-min-version,109100),$(comma)sanitizer)
-# `rustc` recognizes `--remap-path-prefix` since 1.26.0, but `rustdoc` only
-# since Rust 1.81.0. Moreover, `rustdoc` ICEs on out-of-tree builds since Rust
-# 1.82.0 (https://github.com/rust-lang/rust/issues/138520). Thus workaround both
-# issues skipping the flag. The former also applies to `RUSTDOC TK`.
quiet_cmd_rustdoc = RUSTDOC $(if $(rustdoc_host),H, ) $<
cmd_rustdoc = \
OBJTREE=$(abspath $(objtree)) \
- $(RUSTDOC) $(filter-out $(skip_flags) --remap-path-prefix=%,$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
+ $(RUSTDOC) $(filter-out $(skip_flags),$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
$(rustc_target_flags) -L$(objtree)/$(obj) \
-Zunstable-options --generate-link-to-definition \
--output $(rustdoc_output) \
@@ -338,7 +334,7 @@ quiet_cmd_rustdoc_test_kernel = RUSTDOC TK $<
rm -rf $(objtree)/$(obj)/test/doctests/kernel; \
mkdir -p $(objtree)/$(obj)/test/doctests/kernel; \
OBJTREE=$(abspath $(objtree)) \
- $(RUSTDOC) --test $(filter-out --remap-path-prefix=%,$(rust_flags)) \
+ $(RUSTDOC) --test $(rust_flags) \
-L$(objtree)/$(obj) --extern ffi --extern pin_init \
--extern kernel --extern build_error --extern macros \
--extern bindings --extern uapi \
--
2.53.0
^ permalink raw reply related
* [PATCH v2 00/33] rust: bump minimum Rust and `bindgen` versions
From: Miguel Ojeda @ 2026-04-05 23:52 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
we are going to follow Debian Stable's Rust versions as our minimum
supported version.
Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
still uses to this day [3] (i.e. no update to Rust 1.85.1).
Debian Trixie was released with `bindgen` 0.71.1, which it also still
uses to this day [4].
Debian Trixie's release happened on 2025-08-09 [5], which means that a
fair amount of time has passed since its release for kernel developers
to upgrade.
Thus bump the minimum to the new versions, i.e.
- Rust: 1.78.0 -> 1.85.0
- bindgen: 0.65.1 -> 0.71.1
There are a few main parts to the series, in this order:
- A few cleanups that can be performed before the bumps.
- The Rust bump (and its cleanups).
- The `bindgen` bump (and its cleanups).
- Documentation updates.
- The `cfi_encoding` patch, added here, which needs the bump.
- The per-version flags support and a Clippy cleanup on top.
Link: https://lwn.net/Articles/1050174/ [1]
Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]
Link: https://packages.debian.org/trixie/rustc [3]
Link: https://packages.debian.org/trixie/bindgen [4]
Link: https://www.debian.org/releases/trixie/ [5]
---
v1: https://lore.kernel.org/rust-for-linux/20260401114540.30108-1-ojeda@kernel.org/
v2:
- Added patch to globally allow `incompatible_msrv` and removed the
last instance.
- Replaced `--remap-path-prefix` patches with one that drops the
workaround entirely (and place it as the first one) and summarizes
the discussion.
I also noticed that `--remap-path-prefix` for `rustdoc` is still
unstable (unlike `rustc`'s one), so I added it to our list as usual
(https://github.com/Rust-for-Linux/linux/issues/2). There does not
seem to be a tracking issue, so I asked upstream about it.
We will need these two lines as the resolution for the conflict:
$(RUSTDOC) $(filter-out $(skip_flags) --remap-path-scope=%,$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
$(RUSTDOC) --test $(filter-out --remap-path-scope=%,$(rust_flags)) \
- Reworked the `extract_if` patch to use it (unstably). The feature
last major change happened in Rust 1.85.0, so that is fine.
- Moved `$(HOSTRUSTFLAGS)` below so that per-version flags (like
lints) can be overridden too. Please see the details in the commit
and my reply to v1.
- Added `feature(extract_if)` and `feature(non_null_convenience)`
items to https://github.com/Rust-for-Linux/linux/issues/1223.
Then reworded the commits accordingly to include the references
to tracking issues and PRs.
- Other rewords, e.g. the "beyond" typo.
- Rebased on top of `rust-next`.
- Picked up tags.
Alice Ryhl (1):
rust: declare cfi_encoding for lru_status
Miguel Ojeda (32):
rust: kbuild: remove `--remap-path-prefix` workarounds
rust: kbuild: remove "`try` keyword" workaround for `bindgen` < 0.59.2
rust: kbuild: remove unneeded old `allow`s for generated layout tests
gpu: nova-core: bindings: remove unneeded `cfg_attr`
rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
rust: allow globally `clippy::incompatible_msrv`
rust: simplify `RUSTC_VERSION` Kconfig conditions
rust: remove `RUSTC_HAS_SLICE_AS_FLATTENED` and simplify code
rust: remove `RUSTC_HAS_COERCE_POINTEE` and simplify code
rust: kbuild: remove skipping of `-Wrustdoc::unescaped_backticks`
rust: kbuild: remove `feature(...)`s that are now stable
rust: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`
rust: alloc: simplify with `NonNull::add()` now that it is stable
rust: macros: simplify code using `feature(extract_if)`
rust: block: update `const_refs_to_static` MSRV TODO comment
rust: bump `bindgen` minimum supported version to 0.71.1 (Debian
Trixie)
rust: rust_is_available: remove warning for `bindgen` 0.66.[01]
rust: rust_is_available: remove warning for `bindgen` < 0.69.5 &&
libclang >= 19.1
rust: kbuild: update `bindgen --rust-target` version and replace
comment
rust: kbuild: remove "dummy parameter" workaround for `bindgen` <
0.71.1
docs: rust: quick-start: openSUSE provides `rust-src` package nowadays
docs: rust: quick-start: update Ubuntu versioned packages
docs: rust: quick-start: update minimum Ubuntu version
docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection
title
docs: rust: quick-start: remove Gentoo "testing" note
docs: rust: quick-start: remove Nix "unstable channel" note
docs: rust: quick-start: remove GDB/Binutils mention
docs: rust: general-information: simplify Kconfig example
docs: rust: general-information: use real example
rust: kbuild: support global per-version flags
rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
.clippy.toml | 2 +-
Documentation/process/changes.rst | 4 +-
Documentation/rust/general-information.rst | 4 +-
Documentation/rust/quick-start.rst | 52 +++++++----------
Makefile | 12 +++-
arch/Kconfig | 3 +-
arch/arm64/Kconfig | 8 ---
arch/riscv/Kconfig | 3 -
drivers/android/binder/Makefile | 3 +-
drivers/android/binder/page_range.rs | 6 +-
drivers/android/binder/page_range_helper.c | 24 --------
drivers/android/binder/page_range_helper.h | 15 -----
drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-
drivers/gpu/nova-core/gsp/fw/r570_144.rs | 3 -
init/Kconfig | 15 +----
rust/Makefile | 31 ++--------
rust/bindgen_parameters | 8 +--
rust/bindings/bindings_helper.h | 1 -
rust/bindings/lib.rs | 5 +-
rust/kernel/alloc/allocator/iter.rs | 8 +--
rust/kernel/alloc/kbox.rs | 29 +---------
rust/kernel/block/mq/gen_disk.rs | 4 +-
rust/kernel/lib.rs | 30 +---------
rust/kernel/list/arc.rs | 22 +------
rust/kernel/prelude.rs | 3 -
rust/kernel/ptr.rs | 1 -
rust/kernel/slice.rs | 49 ----------------
rust/kernel/sync/arc.rs | 21 +------
rust/kernel/transmute.rs | 35 ++---------
rust/macros/helpers.rs | 1 -
rust/macros/kunit.rs | 9 +--
rust/macros/lib.rs | 3 +
rust/uapi/lib.rs | 5 +-
scripts/Makefile.build | 6 +-
scripts/min-tool-version.sh | 4 +-
scripts/rust_is_available.sh | 36 +-----------
scripts/rust_is_available_bindgen_0_66.h | 2 -
...ust_is_available_bindgen_libclang_concat.h | 3 -
scripts/rust_is_available_test.py | 58 +------------------
39 files changed, 83 insertions(+), 451 deletions(-)
delete mode 100644 drivers/android/binder/page_range_helper.c
delete mode 100644 drivers/android/binder/page_range_helper.h
delete mode 100644 rust/kernel/slice.rs
delete mode 100644 scripts/rust_is_available_bindgen_0_66.h
delete mode 100644 scripts/rust_is_available_bindgen_libclang_concat.h
base-commit: 36f5a2b09e650b82d7b2a106e3b93af48c2010d9
--
2.53.0
^ permalink raw reply
* Re: [PATCH] t10-pi: reduce ref tag code duplication
From: Anuj gupta @ 2026-04-05 23:43 UTC (permalink / raw)
To: Caleb Sander Mateos; +Cc: Jens Axboe, linux-block, linux-kernel
In-Reply-To: <20260403185101.2172135-1-csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
^ permalink raw reply
* Re: [PATCH 5/6] t10-pi: use bio_integrity_intervals() helper
From: Anuj gupta @ 2026-04-05 23:43 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, linux-block, linux-kernel, linux-nvme,
linux-scsi, target-devel
In-Reply-To: <20260403194109.2255933-6-csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
^ permalink raw reply
* Re: [PATCH 32/33] rust: kbuild: support global per-version flags
From: Miguel Ojeda @ 2026-04-05 23:15 UTC (permalink / raw)
To: Gary Guo, Nathan Chancellor, Nicolas Schier
Cc: Miguel Ojeda, Danilo Krummrich, Andreas Hindborg, Catalin Marinas,
Will Deacon, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Courbot, David Airlie, Simona Vetter, Brendan Higgins,
David Gow, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, Alice Ryhl,
Jonathan Corbet, Boqun Feng, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <DHHX9O7V06VZ.G0N1CQ7BUKFO@garyguo.net>
On Thu, Apr 2, 2026 at 12:28 AM Gary Guo <gary@garyguo.net> wrote:
>
> I think I would prefer moving these down.
>
> The current approach append the flags to all variables, which will cause the
> following equivalence to stop holding after the flag update.
>
> KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
> -Zallow-features= $(HOSTRUSTFLAGS)
>
> (Per version flags doesn't go before -O anymore, it comes after HOSTRUSTFLAGS).
[ For context for others, Sashiko reported the same and we also talked
about it in a Rust for Linux call. ]
I have been thinking about this, and about potential other ways to
achieve the same thing. I think the best at the moment is to move just
the `$(HOSTRUSTFLAGS)` below, but not the rest.
The reason is that it is closer to what we do with other user (kernel)
flags (e.g. arch flags come after the general ones). But I am
wondering if we should/could set all the user variables later in the
`Makefile` in general `HOST*FLAGS` later in the `Makefile`.
In fact, there is already a limitation with the host flags: `-Werror`,
i.e. that one gets appended later, and so users cannot override it.
This may be considered a bug, because commit 7ded7d37e5f5
("scripts/Makefile.extrawarn: Respect CONFIG_WERROR / W=e for
hostprogs") says:
While it is
possible to avoid this behavior by passing HOSTCFLAGS=-w or
HOSTCFLAGS=-Wno-error, it may not be the most intuitive for regular
users not intimately familiar with Kbuild.
But passing `HOSTCFLAGS=-Wno-error` doesn't work, since it comes
earlier (`-w` does work, but because it turns off everything).
I am also a bit confused with:
While this means there is a small portion of
the build that does not have -Werror enabled (namely scripts/kconfig/*
and scripts/basic/fixdep)
because it gets enabled in the build (I think it is referring to other
targets like the config ones).
Anyway, for now I moved the expansion of `HOSTRUSTFLAGS` in v2. If
Kbuild (Nathan, Nicolas) think it is a good idea to do one of the
bigger changes (e.g. for more `HOST*` flags, appending it even later),
then we can do it afterwards.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v10 10/13] blk-mq: use hk cpus only when isolcpus=io_queue is enabled
From: Aaron Tomlin @ 2026-04-05 23:09 UTC (permalink / raw)
To: Waiman Long
Cc: axboe, kbusch, hch, sagi, mst, aacraid, James.Bottomley,
martin.petersen, liyihang9, kashyap.desai, sumit.saxena,
shivasharan.srikanteshwara, chandrakanth.patil, sathya.prakash,
sreekanth.reddy, suganath-prabu.subramani, ranjan.kumar,
jinpu.wang, tglx, mingo, peterz, juri.lelli, vincent.guittot,
akpm, maz, ruanjinjie, bigeasy, yphbchou0911, wagi, frederic,
chenridong, hare, kch, ming.lei, steve, sean, chjohnst, neelx,
mproche, linux-block, linux-kernel, virtualization, linux-nvme,
linux-scsi, megaraidlinux.pdl, mpi3mr-linuxdrv.pdl,
MPT-FusionLinux.pdl
In-Reply-To: <c6189740-b741-41e5-a9f6-d09e1ddb86ec@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Thu, Apr 02, 2026 at 10:06:51PM -0400, Waiman Long wrote:
> > diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
> > index 8244ecf87835..8d09af49a142 100644
> > --- a/block/blk-mq-cpumap.c
> > +++ b/block/blk-mq-cpumap.c
> > @@ -22,7 +22,18 @@ static unsigned int blk_mq_num_queues(const struct cpumask *mask,
> > {
> > unsigned int num;
> > - num = cpumask_weight(mask);
> > + if (housekeeping_enabled(HK_TYPE_IO_QUEUE)) {
> > + const struct cpumask *hk_mask;
> > + struct cpumask avail_mask;
> > +
> > + hk_mask = housekeeping_cpumask(HK_TYPE_IO_QUEUE);
> > + cpumask_and(&avail_mask, mask, hk_mask);
> > +
> > + num = cpumask_weight(&avail_mask);
>
> As said before by Ming Lei, struct cpumask can be rather big in size if
> NR_CPUS is large. I will suggest using cpumask_weight_and() instead which
> will eliminate the need of the local variables.
Hi Longman,
I agree. Also, it perfectly circumvents the need for the temporary local
mask while achieving the exact same intersection count.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 23/33] docs: rust: quick-start: update Ubuntu versioned packages
From: Miguel Ojeda @ 2026-04-05 19:35 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434465.73816.4492182082440539007.b4-review@b4>
On Thu, Apr 2, 2026 at 1:01 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> RUST_LIB_SRC is also mentioned in the nix section, do you know if it is
> still needed there?
Yeah, that would be nice to know.
I tried on my own, and it does seem still required (at least with
those packages mentioned in the example). But perhaps a Nix user knows
of a better way to do it, anyway.
So I kept it.
By the way, I think it would be nice to have a "standard",
well-maintained `shell.nix` (or a flake or whatever is best nowadays)
in the kernel tree somewhere, i.e. one that is known to work, that
covers most tooling used in the kernel, etc.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 20/33] rust: kbuild: remove unneeded old `allow`s for generated layout tests
From: Miguel Ojeda @ 2026-04-05 19:31 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434460.73816.4231801886718165891.b4-review@b4>
On Thu, Apr 2, 2026 at 1:01 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> How about ordering this, the previous patch, and the next patch ahead of
> the version bump to avoid the need to mention it here?
That is reasonable, yeah.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 17/33] rust: kbuild: update `bindgen --rust-target` version and replace comment
From: Miguel Ojeda @ 2026-04-05 19:31 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434455.73816.15756486388132647025.b4-review@b4>
On Thu, Apr 2, 2026 at 1:00 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Some citations pointing to the upstream changes would be good.
I added a couple links as usual, plus a reference to commit
7a5f93ea5862 ("rust: kbuild: set `bindgen`'s Rust target version")
that has most of the details.
[ The comment already mentioned the version, and the commit that added
that message has the details, but I agree it is a good idea to add
some references. ]
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 11/33] rust: alloc: simplify with `NonNull::add()` now that it is stable
From: Miguel Ojeda @ 2026-04-05 19:31 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434445.73816.7873322235592463050.b4-review@b4>
On Thu, Apr 2, 2026 at 1:00 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> This description is inconsistent with the previous one which had
> citations for both the feature (function in this case) and the feature
> in which it became stable (available in this case). I don't prefer
> either style in particular, just that things are consistent.
Sure, I added a couple references. I think it is good to be consistent
(well, at least within a patch series, but I wouldn't say no to more
information even if it is inconsistent sometimes, especially across
different patch series, since everyone writes messages a bit
differently...).
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 10/33] rust: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`
From: Miguel Ojeda @ 2026-04-05 19:29 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434443.73816.5437391869400189147.b4-review@b4>
On Thu, Apr 2, 2026 at 1:00 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> "beyond" is probably not the right word here?
I think you are right -- reworded.
Thanks!
Cheers,
Miguel
^ permalink raw reply
* [PATCH v3] drbd: use get_random_u64() where appropriate
From: David Carlier @ 2026-04-05 15:47 UTC (permalink / raw)
To: Philipp Reisner, Lars Ellenberg, Christoph Böhmwalder
Cc: Jens Axboe, drbd-dev, linux-block, linux-kernel, David Carlier
Use the typed random integer helpers instead of
get_random_bytes() when filling a single integer variable.
The helpers return the value directly, require no pointer
or size argument, and better express intent.
Signed-off-by: David Carlier <devnexen@gmail.com>
---
drivers/block/drbd/drbd_main.c | 4 ++--
drivers/block/drbd/drbd_nl.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 200d464e984b..b1a721dd0496 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -874,7 +874,7 @@ void drbd_gen_and_send_sync_uuid(struct drbd_peer_device *peer_device)
if (uuid && uuid != UUID_JUST_CREATED)
uuid = uuid + UUID_NEW_BM_OFFSET;
else
- get_random_bytes(&uuid, sizeof(u64));
+ uuid = get_random_u64();
drbd_uuid_set(device, UI_BITMAP, uuid);
drbd_print_uuids(device, "updated sync UUID");
drbd_md_sync(device);
@@ -3337,7 +3337,7 @@ void drbd_uuid_new_current(struct drbd_device *device) __must_hold(local)
u64 val;
unsigned long long bm_uuid;
- get_random_bytes(&val, sizeof(u64));
+ val = get_random_u64();
spin_lock_irq(&device->ldev->md.uuid_lock);
bm_uuid = device->ldev->md.uuid[UI_BITMAP];
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index e201f0087a0f..377f60b40f28 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -3173,7 +3173,7 @@ int drbd_adm_resume_io(struct sk_buff *skb, struct genl_info *info)
* matching real data uuid exists).
*/
u64 val;
- get_random_bytes(&val, sizeof(u64));
+ val = get_random_u64();
drbd_set_ed_uuid(device, val);
drbd_warn(device, "Resumed without access to data; please tear down before attempting to re-configure.\n");
}
--
2.53.0
^ permalink raw reply related
* Re: [RFC] block/nvme: exploring asynchronous durability notification semantics
From: Hannes Reinecke @ 2026-04-05 12:58 UTC (permalink / raw)
To: Esteban Cerutti, linux-kernel; +Cc: linux-block, linux-nvme
In-Reply-To: <ac7eHEnFQlLN-vDy@yanara>
On 4/2/26 23:22, Esteban Cerutti wrote:
> Hi,
>
> I would like to explore whether current NVMe completion semantics
> unnecessarily conflate execution completion with durability, and
> whether there is room for a more explicit, asynchronous durability
> notification model between host and device.
>
> Today, a successful write completion indicates command execution,
> but not necessarily physical persistence to non-volatile media unless
> FUA or Flush is used. This forces the kernel and filesystems to assume
> worst-case durability behavior and rely on synchronous flushes and
> barriers for safety.
>
Not necessarily. Synchronous flushes and barriers are really only
an issue for ext4 (which happens to rely on that). Other filesystems
like btrfs work happily without that.
It's more a design choice; explicit flushes guarantee global visibility,
something which you need if you have things like superblocks at fixed
positions. But if you haven't (like btrfs) than you are perfectly fine
using per-request flushes (eg to ensure the log has been written), and
then you don't need a global flush.
> The device internally knows when data is staged in volatile buffers
> versus committed to NAND (or equivalent persistent media), but this
> information is not exposed to the host.
>
... and not available to the host.
I'm not aware of any command (or I/O completion information) which
would tell you if and when an I/O cached internally in the drive is
written to disk.
> This RFC explores a potential extension model with two components:
>
> 1) Multi-phase completion semantics
>
> - Normal completion continues to signal execution.
> - The device assigns a persistence token ID.
> - When the data is physically committed to non-volatile media,
> the device emits an asynchronous durability confirmation
> referencing that token.
>
> This would decouple execution throughput from durability
> confirmation and potentially allow filesystems to close journal
> transactions only upon confirmed persistence, without forcing
> synchronous flush fences.
>
... or redesign your filesystem to _not_ rely on synchronous flushes.
> 2) Advisory write intent classification
>
> - Host-provided hints such as EPHEMERAL, STANDARD, or CRITICAL.
> - CRITICAL writes would request immediate durability.
> - EPHEMERAL writes could tolerate extended volatile staging.
>
> Additionally, I am curious whether host power-state awareness
> could be relevant in such a model. For example, if the kernel
> can detect battery-backed operation or confirmed UPS
> infrastructure, it could advertise a bounded persistence
> relaxation window (e.g. guaranteed power for N ms), allowing
> the device to safely extend volatile staging within that
> window. This would be advisory and revocable, not a mandatory
> trust model.
>
Been there, done that. Really hard to ensure.
Some RAID controllers try to do something here by not
advertising volatile cache if battery backup is not present,
but that's a really lame thing as you need to ensure that
you have enough power to keep the HDDs running after a
power outage until you have written out all data.
It's getting even harder for on-board HBAs where you have
no distinct power rails for the HDDs; you'd need to have
a battery large enough to keep the entire system running,
but that would be massively overprovisioned for 99% of the
time. And hence far too expensive.
Doubt it's worth it.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH 6/6] target: use bio_integrity_intervals() helper
From: Anuj gupta @ 2026-04-05 11:29 UTC (permalink / raw)
To: Caleb Sander Mateos, Anuj Gupta
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, linux-block, linux-kernel, linux-nvme,
linux-scsi, target-devel
In-Reply-To: <20260403194109.2255933-7-csander@purestorage.com>
Looks ok to me.
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
^ permalink raw reply
* Re: [PATCH 4/6] bio-integrity-fs: use integrity interval instead of sector as seed
From: Anuj gupta @ 2026-04-05 11:29 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, linux-block, linux-kernel, linux-nvme,
linux-scsi, target-devel
In-Reply-To: <20260403194109.2255933-5-csander@purestorage.com>
Looks ok to me.
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
^ permalink raw reply
* Re: [PATCH 3/6] bio-integrity-fs: pass data iter to bio_integrity_verify()
From: Anuj gupta @ 2026-04-05 11:28 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, linux-block, linux-kernel, linux-nvme,
linux-scsi, target-devel, Anuj Gupta
In-Reply-To: <20260403194109.2255933-4-csander@purestorage.com>
> bio_integrity_verify() expects the passed struct bvec_iter to be an
> iterator over bio data, not integrity. So construct a separate data
> bvec_iter without the bio_integrity_bytes() conversion and pass it to
> bio_integrity_verify() instead of bip_iter.
Good catch!
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
^ permalink raw reply
* Re: [PATCH 2/6] block: use integrity interval instead of sector as seed
From: Anuj gupta @ 2026-04-05 11:27 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, linux-block, linux-kernel, linux-nvme,
linux-scsi, target-devel, Anuj Gupta
In-Reply-To: <20260403194109.2255933-3-csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
^ permalink raw reply
* Re: [PATCH 1/6] blk-integrity: take sector_t in bio_integrity_intervals()
From: Anuj gupta @ 2026-04-05 11:27 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, linux-block, linux-kernel, linux-nvme,
linux-scsi, target-devel, Anuj Gupta
In-Reply-To: <20260403194109.2255933-2-csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
^ permalink raw reply
* Re: [PATCH 0/6] block: fix integrity offset/length conversions
From: Anuj gupta @ 2026-04-05 11:26 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, linux-block, linux-kernel, linux-nvme,
linux-scsi, target-devel
In-Reply-To: <20260403194109.2255933-1-csander@purestorage.com>
> The block layer's integrity code currently sets the seed (initial
> reference tag) in units of 512-byte sectors but increments it in units
> of integrity intervals. Not only do the T10 DIF formats require ref tags
> to be the lower bits of the logical block address, but mixing the two
> units means the ref tags used for a particular logical block vary based
> on its offset within a read/write request. This looks to be a
> longstanding bug affecting block devices that support integrity with
> block sizes > 512 bytes; I'm surprised it wasn't noticed before.
>
This likely went unnoticed because the remap path compensates for it:
blk_integrity_prepare() rewrites the host-side sector-based ref tag to
the correct device-visible interval/LBA value, and
blk_integrity_complete() rewrites it back on reads. So for block-auto
PI, and for the FS-PI path that goes through the same remap, the
device-facing ref tag still comes out correct even though the host-side
seed is semantically wrong.
^ permalink raw reply
* Re: [PATCH 1/2] ublk: reset per-IO canceled flag on each fetch
From: zhang @ 2026-04-05 1:02 UTC (permalink / raw)
To: ming.lei
Cc: axboe, csander, linux-block, linux-kernel, linux-kselftest, shuah,
ushankar
In-Reply-To: <adER-jg0JfkE4I8n@fedora>
Dear Ming Lei:
I just looked at your solution, which is to reset immediately after each IO is claimed. This solution can indeed effectively solve the blocking problem. However, if there is a task that is repeated and exactly the same, then the process may run repeatedly many times. Do you think we should add some logic to handle repeated tasks?
Reviewed-by: zhang, the-essence-of-life.
--
the-essence-of-life
^ permalink raw reply
* Re: [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
From: Yuto Ohnuki @ 2026-04-04 14:56 UTC (permalink / raw)
To: Jens Axboe
Cc: Yu Kuai, Nilay Shroff, Ming Lei, linux-block, linux-kernel,
syzbot+71fcf20f7c1e5043d78c
In-Reply-To: <20260316070358.65225-2-ytohnuki@amazon.com>
On Mon, Mar 16, 2026 at 07:03:59AM +0000, Yuto Ohnuki wrote:
> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
> wbt_alloc() and wbt_init(). However, both are expected failure paths:
>
> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)
> - wbt_init() can fail with -EBUSY if wbt is already registered
>
> syzbot triggers this by injecting memory allocation failures during MTD
> partition creation via ioctl(BLKPG), causing a spurious warning.
>
> wbt_init_enable_default() is a best-effort initialization called from
> blk_register_queue() with a void return type. Failure simply means the
> disk operates without writeback throttling, which is harmless.
>
> Replace WARN_ON_ONCE with plain if-checks, consistent with how
> wbt_set_lat() in the same file already handles these failures. Add a
> pr_warn() for the wbt_init() failure to retain diagnostic information
> without triggering a full stack trace.
>
> Reported-by: syzbot+71fcf20f7c1e5043d78c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=71fcf20f7c1e5043d78c
> Fixes: 41afaeeda509 ("blk-wbt: fix possible deadlock to nest pcpu_alloc_mutex under q_usage_counter")
> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
> ---
> Changes in v2:
> - Add pr_warn() for wbt_init() failure as suggested by Yu Kuai
> - Link to v1: https://lore.kernel.org/all/20260315143137.13547-2-ytohnuki@amazon.com/
> ---
> block/blk-wbt.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-wbt.c b/block/blk-wbt.c
> index 33006edfccd4..dcc2438ca16d 100644
> --- a/block/blk-wbt.c
> +++ b/block/blk-wbt.c
> @@ -782,10 +782,11 @@ void wbt_init_enable_default(struct gendisk *disk)
> return;
>
> rwb = wbt_alloc();
> - if (WARN_ON_ONCE(!rwb))
> + if (!rwb)
> return;
>
> - if (WARN_ON_ONCE(wbt_init(disk, rwb))) {
> + if (wbt_init(disk, rwb)) {
> + pr_warn("%s: failed to enable wbt\n", disk->disk_name);
> wbt_free(rwb);
> return;
> }
> --
> 2.50.1
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
>
>
>
Gentle ping on this patch.
It has a Reviewed-by from Nilay Shroff and Yu Kuai.
Please let me know if there is anything else needed for this
to be applied.
Thank you in advance,
Yuto
Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
^ permalink raw reply
* Re: [PATCH] bdev: remove unused BVEC_ITER_ALL_INIT
From: Jens Axboe @ 2026-04-04 14:10 UTC (permalink / raw)
To: Caleb Sander Mateos; +Cc: linux-block, linux-kernel
In-Reply-To: <20260403184852.2140919-1-csander@purestorage.com>
On Fri, 03 Apr 2026 12:48:51 -0600, Caleb Sander Mateos wrote:
> This macro no longer has any users, so remove it.
Applied, thanks!
[1/1] bdev: remove unused BVEC_ITER_ALL_INIT
commit: 8b155f2e4a91f3507951e6ace4b413688ac28b96
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 2/2] selftests: ublk: test that teardown after incomplete recovery completes
From: Ming Lei @ 2026-04-04 13:33 UTC (permalink / raw)
To: Uday Shankar
Cc: Caleb Sander Mateos, Jens Axboe, Shuah Khan, linux-block,
linux-kernel, linux-kselftest
In-Reply-To: <20260403-cancel-v1-2-86e5a6b3d3af@purestorage.com>
On Fri, Apr 03, 2026 at 09:23:56PM -0600, Uday Shankar wrote:
> Before the fix, teardown of a ublk server that was attempting to recover
> a device, but died when it had submitted a nonempty proper subset of the
> fetch commands to any queue would loop forever. Add a test to verify
> that, after the fix, teardown completes. This is done by:
>
> - Adding a new argument to the fault_inject target that causes it die
> after fetching a nonempty proper subset of the IOs to a queue
> - Using that argument in a new test while trying to recover an
> already-created device
> - Attempting to delete the ublk device at the end of the test; this
> hangs forever if teardown from the fault-injected ublk server never
> completed.
>
> It was manually verified that the test passes with the fix and hangs
> without it.
>
> Signed-off-by: Uday Shankar <ushankar@purestorage.com>
> ---
> tools/testing/selftests/ublk/Makefile | 1 +
> tools/testing/selftests/ublk/fault_inject.c | 51 +++++++++++++++++++++++--
> tools/testing/selftests/ublk/kublk.c | 4 ++
> tools/testing/selftests/ublk/kublk.h | 3 ++
> tools/testing/selftests/ublk/test_generic_17.sh | 35 +++++++++++++++++
> 5 files changed, 91 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/ublk/Makefile b/tools/testing/selftests/ublk/Makefile
> index 8ac2d4a682a1768fb1eb9d2dd2a5d01294a67a03..d338668c5a5fbd73f6d70165455a3551ab13e894 100644
> --- a/tools/testing/selftests/ublk/Makefile
> +++ b/tools/testing/selftests/ublk/Makefile
> @@ -18,6 +18,7 @@ TEST_PROGS += test_generic_10.sh
> TEST_PROGS += test_generic_12.sh
> TEST_PROGS += test_generic_13.sh
> TEST_PROGS += test_generic_16.sh
> +TEST_PROGS += test_generic_17.sh
>
> TEST_PROGS += test_batch_01.sh
> TEST_PROGS += test_batch_02.sh
> diff --git a/tools/testing/selftests/ublk/fault_inject.c b/tools/testing/selftests/ublk/fault_inject.c
> index 3b897f69c014cc73b4b469d816e80284dd21b577..228a9605053409c84baaf255f97c4abc271a8bfd 100644
> --- a/tools/testing/selftests/ublk/fault_inject.c
> +++ b/tools/testing/selftests/ublk/fault_inject.c
> @@ -10,11 +10,17 @@
>
> #include "kublk.h"
>
> +struct fi_opts {
> + long long delay_ns;
> + bool die_during_fetch;
> +};
> +
> static int ublk_fault_inject_tgt_init(const struct dev_ctx *ctx,
> struct ublk_dev *dev)
> {
> const struct ublksrv_ctrl_dev_info *info = &dev->dev_info;
> unsigned long dev_size = 250UL << 30;
> + struct fi_opts *opts = NULL;
>
> if (ctx->auto_zc_fallback) {
> ublk_err("%s: not support auto_zc_fallback\n", __func__);
> @@ -35,17 +41,51 @@ static int ublk_fault_inject_tgt_init(const struct dev_ctx *ctx,
> };
> ublk_set_integrity_params(ctx, &dev->tgt.params);
>
> - dev->private_data = (void *)(unsigned long)(ctx->fault_inject.delay_us * 1000);
> + opts = calloc(1, sizeof(*opts));
> + if (!opts) {
> + ublk_err("%s: couldn't allocate memory for opts\n", __func__);
> + return -ENOMEM;
> + }
> +
> + opts->delay_ns = ctx->fault_inject.delay_us * 1000;
> + opts->die_during_fetch = ctx->fault_inject.die_during_fetch;
> + dev->private_data = opts;
> +
> return 0;
> }
>
> +static void ublk_fault_inject_pre_fetch_io(struct ublk_thread *t,
> + struct ublk_queue *q, int tag)
> +{
> + struct fi_opts *opts = q->dev->private_data;
> +
> + if (!opts->die_during_fetch)
> + return;
> +
> + /*
> + * Each queue fetches its IOs in increasing order of tags, so
> + * dying just before we're about to fetch tag 1 (regardless of
> + * what queue we're on) guarantees that we've fetched a nonempty
> + * proper subset of the tags on that queue.
> + */
> + if (tag == 1) {
> + /*
> + * Ensure our commands are actually live in the kernel
> + * before we die.
> + */
> + io_uring_submit(&t->ring);
> + raise(SIGKILL);
> + }
> +}
> +
> static int ublk_fault_inject_queue_io(struct ublk_thread *t,
> struct ublk_queue *q, int tag)
> {
> const struct ublksrv_io_desc *iod = ublk_get_iod(q, tag);
> struct io_uring_sqe *sqe;
> + struct fi_opts *opts = q->dev->private_data;
> struct __kernel_timespec ts = {
> - .tv_nsec = (long long)q->dev->private_data,
> + .tv_nsec = opts->delay_ns,
> };
>
> ublk_io_alloc_sqes(t, &sqe, 1);
> @@ -77,29 +117,34 @@ static void ublk_fault_inject_cmd_line(struct dev_ctx *ctx, int argc, char *argv
> {
> static const struct option longopts[] = {
> { "delay_us", 1, NULL, 0 },
> + { "die_during_fetch", 1, NULL, 0 },
> { 0, 0, 0, 0 }
> };
> int option_idx, opt;
>
> ctx->fault_inject.delay_us = 0;
> + ctx->fault_inject.die_during_fetch = false;
> while ((opt = getopt_long(argc, argv, "",
> longopts, &option_idx)) != -1) {
> switch (opt) {
> case 0:
> if (!strcmp(longopts[option_idx].name, "delay_us"))
> ctx->fault_inject.delay_us = strtoll(optarg, NULL, 10);
> + if (!strcmp(longopts[option_idx].name, "die_during_fetch"))
> + ctx->fault_inject.die_during_fetch = strtoll(optarg, NULL, 10);
> }
> }
> }
>
> static void ublk_fault_inject_usage(const struct ublk_tgt_ops *ops)
> {
> - printf("\tfault_inject: [--delay_us us (default 0)]\n");
> + printf("\tfault_inject: [--delay_us us (default 0)] [--die_during_fetch 1]\n");
> }
>
> const struct ublk_tgt_ops fault_inject_tgt_ops = {
> .name = "fault_inject",
> .init_tgt = ublk_fault_inject_tgt_init,
> + .pre_fetch_io = ublk_fault_inject_pre_fetch_io,
> .queue_io = ublk_fault_inject_queue_io,
> .tgt_io_done = ublk_fault_inject_tgt_io_done,
> .parse_cmd_line = ublk_fault_inject_cmd_line,
> diff --git a/tools/testing/selftests/ublk/kublk.c b/tools/testing/selftests/ublk/kublk.c
> index e1c3b3c55e565c8cad6b6fe9b9b764cd244818c0..8260c96a39c05584065f41a52f3d9050614454c6 100644
> --- a/tools/testing/selftests/ublk/kublk.c
> +++ b/tools/testing/selftests/ublk/kublk.c
> @@ -796,6 +796,8 @@ static void ublk_submit_fetch_commands(struct ublk_thread *t)
> q = &t->dev->q[q_id];
> io = &q->ios[tag];
> io->buf_index = j++;
> + if (q->tgt_ops->pre_fetch_io)
> + q->tgt_ops->pre_fetch_io(t, q, tag);
> ublk_queue_io_cmd(t, io);
> }
> } else {
> @@ -807,6 +809,8 @@ static void ublk_submit_fetch_commands(struct ublk_thread *t)
> for (i = 0; i < q->q_depth; i++) {
> io = &q->ios[i];
> io->buf_index = i;
> + if (q->tgt_ops->pre_fetch_io)
> + q->tgt_ops->pre_fetch_io(t, q, i);
> ublk_queue_io_cmd(t, io);
> }
> }
The callback needs to be called in ublk_batch_setup_queues() for F_BATCH
too.
Otherwise, this patch looks good.
Thanks,
Ming
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox