linux-stable.git/rust/kernel, branch v7.1.5 Linux kernel stable tree rust: alloc: fix assert in `Vec::reserve` doc test 2026-07-24T14:20:00+00:00 Hsiu Che Yu yu.whisper.personal@gmail.com 2026-04-27T14:15:49+00:00 34b2a1076dd71b979e60056721e0811fcdcd1800 [ Upstream commit 75619f2df7a5da6ffb61eedc2a73fdf70c65471c ] The assert in the doctest used `>= 10`, which only checks that the capacity can hold `additional` elements, ignoring the existing length of `v`. The correct check should ensure there is room for `additional` *extra* elements on top of what is already in the vector. Fix the assert to use `>= v.len() + 10` so the example accurately reflects the actual semantics of the function. Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Closes: https://lore.kernel.org/rust-for-linux/CANiq72nkXWhjK9iFRrhGtkMZGsvNE_zVsu4JnxaFRfxWL7RRdg@mail.gmail.com/ Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type") Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260427-doctest-kvec-reserve-v1-1-0623abcd9c2e@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 75619f2df7a5da6ffb61eedc2a73fdf70c65471c ]

The assert in the doctest used `>= 10`, which only checks that the
capacity can hold `additional` elements, ignoring the existing length
of `v`. The correct check should ensure there is room for `additional`
*extra* elements on top of what is already in the vector.

Fix the assert to use `>= v.len() + 10` so the example accurately
reflects the actual semantics of the function.

Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Closes: https://lore.kernel.org/rust-for-linux/CANiq72nkXWhjK9iFRrhGtkMZGsvNE_zVsu4JnxaFRfxWL7RRdg@mail.gmail.com/
Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type")
Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260427-doctest-kvec-reserve-v1-1-0623abcd9c2e@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: devres: add 'static bound to Devres<T> 2026-07-24T14:19:23+00:00 Danilo Krummrich dakr@kernel.org 2026-05-26T00:04:41+00:00 146580b2cef4a02b068a74ed54e7f097bc3637d6 [ Upstream commit 016267b521b18529c977c9eca9597a1669c3d73c ] Devres::new() registers a callback with the C devres subsystem via devres_node_add(). If the Devres is leaked (e.g. via core::mem::forget(), which is safe), its Drop impl never runs, and the devres release callback will revoke the inner Revocable on device unbind, which drops T in place. If T contains non-'static references, those may be dangling by that point. Add a 'static bound to prevent storing types with borrowed data in Devres. Fixes: 76c01ded724b ("rust: add devres abstraction") Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260526000447.350558-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 016267b521b18529c977c9eca9597a1669c3d73c ]

Devres::new() registers a callback with the C devres subsystem via
devres_node_add(). If the Devres is leaked (e.g. via
core::mem::forget(), which is safe), its Drop impl never runs, and the
devres release callback will revoke the inner Revocable on device
unbind, which drops T in place. If T contains non-'static references,
those may be dangling by that point.

Add a 'static bound to prevent storing types with borrowed data in
Devres.

Fixes: 76c01ded724b ("rust: add devres abstraction")
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260526000447.350558-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: alloc: fix `Vec::extend_with` SAFETY comment 2026-07-24T14:19:12+00:00 Hsiu Che Yu yu.whisper.personal@gmail.com 2026-04-25T10:16:19+00:00 a2da42614ca75e276a60922ccbcfa42d61b14547 [ Upstream commit f497aae6ded43f91b1dbf29a35d7062823635640 ] Fix an incorrect operator in the SAFETY comment, changing `<` to `<=`, since `Vec::reserve` guarantees capacity for exactly n additional elements, so the equal case should be included. Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type") Link: https://patch.msgid.link/18fc8eee2f057a6bfbcadae156d1d0b7c40d0077.1777111268.git.yu.whisper.personal@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f497aae6ded43f91b1dbf29a35d7062823635640 ]

Fix an incorrect operator in the SAFETY comment, changing `<` to `<=`,
since `Vec::reserve` guarantees capacity for exactly n additional elements,
so the equal case should be included.

Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type")
Link: https://patch.msgid.link/18fc8eee2f057a6bfbcadae156d1d0b7c40d0077.1777111268.git.yu.whisper.personal@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: block: fix GenDisk cleanup paths 2026-07-18T14:55:16+00:00 Haoze Xie royenheart@gmail.com 2026-05-30T06:11:54+00:00 6822a2685b4da9a87efd1fce4b042678a31ff734 commit 2957771379fa335103a4b539db57bb2271e12142 upstream. GenDiskBuilder::build() still has fallible work after __blk_mq_alloc_disk(), but its error path only recovers the foreign queue data. That leaks the temporary gendisk and request_queue until later teardown. If the caller moved the last Arc<TagSet<T>> into build(), the leaked queue can retain blk-mq state after the tag set is dropped. Fix the pre-registration failure path by dropping the temporary gendisk reference with put_disk() before recovering queue_data, so disk_release() can tear down the owned queue. Also pair GenDisk::drop() with put_disk() after del_gendisk(). Once a Rust GenDisk has been added with device_add_disk(), del_gendisk() only unregisters it; the final gendisk reference still has to be dropped to complete the release path. Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Cc: stable@kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Haoze Xie <royenheart@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Link: https://patch.msgid.link/b70aff9a920cc42110fe5cf454c3099561863519.1780063368.git.royenheart@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2957771379fa335103a4b539db57bb2271e12142 upstream.

GenDiskBuilder::build() still has fallible work after
__blk_mq_alloc_disk(), but its error path only recovers the
foreign queue data. That leaks the temporary gendisk and
request_queue until later teardown. If the caller moved the last
Arc<TagSet<T>> into build(), the leaked queue can retain blk-mq
state after the tag set is dropped.

Fix the pre-registration failure path by dropping the temporary
gendisk reference with put_disk() before recovering queue_data,
so disk_release() can tear down the owned queue.

Also pair GenDisk::drop() with put_disk() after del_gendisk().
Once a Rust GenDisk has been added with device_add_disk(),
del_gendisk() only unregisters it; the final gendisk reference
still has to be dropped to complete the release path.

Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
Cc: stable@kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Haoze Xie <royenheart@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Link: https://patch.msgid.link/b70aff9a920cc42110fe5cf454c3099561863519.1780063368.git.royenheart@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: pci: use 'static lifetime for PCI BAR resource names 2026-07-18T14:55:16+00:00 Danilo Krummrich dakr@kernel.org 2026-05-25T20:20:48+00:00 afa40a46407208b08b56e149ea6a1f1d304efe94 commit e566a9e17f3774c962b6d2522750f227f027edc6 upstream. pci_request_region() stores the name pointer directly in struct resource; use &'static CStr to ensure the pointer remains valid even if the Bar is leaked. Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260522004943.CDA7C1F000E9@smtp.kernel.org/ Fixes: 3c2e31d717ac ("rust: pci: move I/O infrastructure to separate file") Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260525202921.124698-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e566a9e17f3774c962b6d2522750f227f027edc6 upstream.

pci_request_region() stores the name pointer directly in struct
resource; use &'static CStr to ensure the pointer remains valid even if
the Bar is leaked.

Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260522004943.CDA7C1F000E9@smtp.kernel.org/
Fixes: 3c2e31d717ac ("rust: pci: move I/O infrastructure to separate file")
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: cpufreq: clean new `clippy::map_or_identity` lint for Rust 1.98.0 2026-07-18T14:55:16+00:00 Miguel Ojeda ojeda@kernel.org 2026-05-30T09:58:09+00:00 3f096fb8647bb95aa42733303780d62e68db485e commit 3473e0a219fdb2cb013da0a5d917e66fef052325 upstream. Starting with Rust 1.98.0 (expected 2026-08-20), Clippy is likely introducing a new lint `clippy::map_or_identity` [1][2], which currently triggers in a single case: warning: expression can be simplified using `Result::unwrap_or()` --> rust/kernel/cpufreq.rs:1326:60 | 1326 | PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).map_or(0, |f| f)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_or_identity = note: `-W clippy::map-or-identity` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::map_or_identity)]` help: consider using `unwrap_or` | 1326 - PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).map_or(0, |f| f)) 1326 + PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).unwrap_or(0)) | The suggestion is valid, thus clean it up. Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://github.com/rust-lang/rust-clippy/issues/15801 [1] Link: https://github.com/rust-lang/rust-clippy/pull/16052 [2] Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260530095809.213611-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3473e0a219fdb2cb013da0a5d917e66fef052325 upstream.

Starting with Rust 1.98.0 (expected 2026-08-20), Clippy is likely
introducing a new lint `clippy::map_or_identity` [1][2], which currently
triggers in a single case:

    warning: expression can be simplified using `Result::unwrap_or()`
        --> rust/kernel/cpufreq.rs:1326:60
         |
    1326 |         PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).map_or(0, |f| f))
         |                                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         |
         = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_or_identity
         = note: `-W clippy::map-or-identity` implied by `-W clippy::all`
         = help: to override `-W clippy::all` add `#[allow(clippy::map_or_identity)]`
    help: consider using `unwrap_or`
         |
    1326 -         PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).map_or(0, |f| f))
    1326 +         PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).unwrap_or(0))
         |

The suggestion is valid, thus clean it up.

Cc: stable@vger.kernel.org # Needed in 6.18.y and later.
Link: https://github.com/rust-lang/rust-clippy/issues/15801 [1]
Link: https://github.com/rust-lang/rust-clippy/pull/16052 [2]
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20260530095809.213611-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: str: clean unused import for Rust >= 1.98 2026-07-18T14:55:15+00:00 Miguel Ojeda ojeda@kernel.org 2026-06-09T10:41:52+00:00 6537884e9cf2f415bfba38a93d7bdef291dd3867 [ Upstream commit 3fff4271809b57182c4011811e96556bdd4cb2f9 ] Starting with Rust 1.98.0 (expected 2026-08-20), the compiler has changed how the resolution algorithm works [1] in upstream commit c4d84db5f184 ("Resolver: Batched import resolution."), and it now spots: error: unused import: `flags::*` --> rust/kernel/str.rs:7:9 | 7 | flags::*, | ^^^^^^^^ | = note: `-D unused-imports` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unused_imports)]` It happens to not be needed because the `prelude::*` already provides the flags. Thus clean it up. Cc: stable@vger.kernel.org # Needed in 6.18.y and later (prelude added to `str`). Link: https://github.com/rust-lang/rust/pull/145108 [1] Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260609104152.261145-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3fff4271809b57182c4011811e96556bdd4cb2f9 ]

Starting with Rust 1.98.0 (expected 2026-08-20), the compiler has changed
how the resolution algorithm works [1] in upstream commit c4d84db5f184
("Resolver: Batched import resolution."), and it now spots:

    error: unused import: `flags::*`
     --> rust/kernel/str.rs:7:9
      |
    7 |         flags::*,
      |         ^^^^^^^^
      |
      = note: `-D unused-imports` implied by `-D warnings`
      = help: to override `-D warnings` add `#[allow(unused_imports)]`

It happens to not be needed because the `prelude::*` already provides
the flags.

Thus clean it up.

Cc: stable@vger.kernel.org # Needed in 6.18.y and later (prelude added to `str`).
Link: https://github.com/rust-lang/rust/pull/145108 [1]
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260609104152.261145-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: str: use the "kernel vertical" imports style 2026-07-18T14:55:15+00:00 Miguel Ojeda ojeda@kernel.org 2026-06-09T10:41:51+00:00 77ddefb1aedaf99480cfe5e1a034f7130f7957c0 [ Upstream commit 724a93a9f6033800b02a3530dbcb464638448e7f ] Convert the imports to use the "kernel vertical" imports style [1]. No functional changes intended. Link: https://docs.kernel.org/rust/coding-guidelines.html#imports [1] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260609104152.261145-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Stable-dep-of: 3fff4271809b ("rust: str: clean unused import for Rust >= 1.98") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 724a93a9f6033800b02a3530dbcb464638448e7f ]

Convert the imports to use the "kernel vertical" imports style [1].

No functional changes intended.

Link: https://docs.kernel.org/rust/coding-guidelines.html#imports [1]
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260609104152.261145-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Stable-dep-of: 3fff4271809b ("rust: str: clean unused import for Rust >= 1.98")
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: i2c: fix I2cAdapter refcounts double increment 2026-06-06T14:19:27+00:00 Nicolás Antinori nico.antinori.7@gmail.com 2026-05-31T18:23:07+00:00 4eb422482ca5d924d7212ad2ca1cb7ea6f5b524d When `I2cAdapter::get` executes, it first calls `bindings::i2c_get_adapter()` which increments the device and module reference counts. It then takes a reference to the raw pointer and converts it to an `ARef` via `.into()`. The implementation of `From<&T> for ARef<T>` where `T: AlwaysRefCounted` unconditionally calls `T::inc_ref()`. This leads to a second increment to the reference counts. Since the returned `ARef` will only release a single reference when dropped via `dec_ref()`, this leaks one device and module reference count on every call. This fix was suggested by sashiko.dev. Link: https://sashiko.dev/#/patchset/20260521190937.248904-1-nico.antinori.7@gmail.com Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com> Reviewed-by: Igor Korotin <igor.korotin@linux.dev> Signed-off-by: Igor Korotin <igor.korotin@linux.dev> 
When `I2cAdapter::get` executes, it first calls
`bindings::i2c_get_adapter()` which increments the device and module
reference counts. It then takes a reference to the raw pointer and
converts it to an `ARef` via `.into()`.

The implementation of `From<&T> for ARef<T>` where `T: AlwaysRefCounted`
unconditionally calls `T::inc_ref()`. This leads to a second increment
to the reference counts.

Since the returned `ARef` will only release a single reference when
dropped via `dec_ref()`, this leaks one device and module reference count
on every call.

This fix was suggested by sashiko.dev.

Link: https://sashiko.dev/#/patchset/20260521190937.248904-1-nico.antinori.7@gmail.com
Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
Reviewed-by: Igor Korotin <igor.korotin@linux.dev>
Signed-off-by: Igor Korotin <igor.korotin@linux.dev>
rust: drm: fix unsound initialization in drm::Device::new 2026-05-03T12:04:57+00:00 Eliot Courtney ecourtney@nvidia.com 2026-05-01T10:49:37+00:00 0a69ac25bd596d50823d530d0a2004336668c0df If pinned initialization of drm::Device::Data fails, it calls drm::Device::release via drm_dev_put. This materializes a reference to &drm::Device, but it's not fully constructed yet, because initializing `data` failed. It should not be dropped either. Instead, if pinned initialization fails, make sure drm::Device::release isn't called. Fixes: 2e9fdbe5ec7a ("rust: drm: device: drop_in_place() the drm::Device in release()") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260501-fix-drm-1-v2-1-5c4f681837bc@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> 
If pinned initialization of drm::Device::Data fails, it calls
drm::Device::release via drm_dev_put. This materializes a reference to
&drm::Device, but it's not fully constructed yet, because initializing
`data` failed. It should not be dropped either. Instead, if pinned
initialization fails, make sure drm::Device::release isn't called.

Fixes: 2e9fdbe5ec7a ("rust: drm: device: drop_in_place() the drm::Device in release()")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260501-fix-drm-1-v2-1-5c4f681837bc@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>