linux-stable.git/rust/kernel, branch v7.2.6 Linux kernel stable tree rust: cpufreq: Fix temporary write in Registration::bios_limit_callback 2026-09-14T11:40:23+00:00 Priya Bala Govindasamy pgovind2@uci.edu 2026-07-20T18:00:58+00:00 35a125c9abbf70355dbda6dd38d8b37d84447b4b [ Upstream commit 19c76bdd3fc02475c73c8576f6f4a55ff07886f1 ] In `Registration::bios_limit_callback`, the expression `&mut (unsafe { *limit })` creates a reference to a temporary copy of the value pointed to by `limit` on the stack. Therefore, writes made by `T::bios_limit` go to this temporary instead of the memory location pointed to by `limit`. Additionally, `limit` may be uninitialized, such as when `Registration::bios_limit_callback` is invoked by `show_bios_limit` in drivers/cpufreq/cpufreq.c. Therefore creating a reference to `limit` is unsound. Fix this by changing the signature of `T::bios_limit` to return the limit value. `Registration::bios_limit_callback` can then update `limit` directly. Fixes: c6af9a1191d042839e56abff69e8b0302d117988 ("rust: cpufreq: Extend abstractions for driver registration") Reported-by: Dylan Zueck<dzueck@uci.edu> Reported-by: Yuan Tan<ytan089@ucr.edu> Assisted-by: ChatGPT:gpt-5.4 Signed-off-by: Priya Bala Govindasamy<pgovind2@uci.edu> [ Viresh: Fix rustfmtcheck warning ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 19c76bdd3fc02475c73c8576f6f4a55ff07886f1 ]

In `Registration::bios_limit_callback`, the expression
`&mut (unsafe { *limit })` creates a reference to a temporary copy
of the value pointed to by `limit` on the stack.
Therefore, writes made by `T::bios_limit` go to this temporary
instead of the memory location pointed to by `limit`.

Additionally, `limit` may be uninitialized, such as when
`Registration::bios_limit_callback` is invoked by `show_bios_limit`
in drivers/cpufreq/cpufreq.c. Therefore creating a reference to
`limit` is unsound.

Fix this by changing the signature of `T::bios_limit` to return the limit
value.
`Registration::bios_limit_callback` can then update `limit` directly.

Fixes: c6af9a1191d042839e56abff69e8b0302d117988 ("rust: cpufreq: Extend abstractions for driver registration")
Reported-by: Dylan Zueck<dzueck@uci.edu>
Reported-by: Yuan Tan<ytan089@ucr.edu>
Assisted-by: ChatGPT:gpt-5.4
Signed-off-by: Priya Bala Govindasamy<pgovind2@uci.edu>
[ Viresh: Fix rustfmtcheck warning ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in TableBuilder::to_table 2026-09-14T11:40:23+00:00 Priya Bala Govindasamy pgovind2@uci.edu 2026-07-20T20:50:35+00:00 04ac4e270e3d30a1948aaacfbaffbc393cd03cdd [ Upstream commit b5e4771f20a37fdf19eac0824bf062dffb4e291f ] The `TableBuilder::to_table` function adds `Hertz(c_ulong::MAX).as_khz()` as the last frequency entry in the frequency table. But the C API expects the last entry to have frequency set to `CPUFREQ_TABLE_END` which is `~1u` as per include/linux/cpufreq.h. Fix this by setting the last frequency entry to `CPUFREQ_TABLE_END` instead of `Hertz(c_ulong::MAX).as_khz()`. Fixes: 2207856ff0bc8d953d6e89bda70b8978c2de8bab ("rust: cpufreq: Add initial abstractions for cpufreq framework") Reported-by: Dylan Zueck<dzueck@uci.edu> Reported-by: Yuan Tan<ytan089@ucr.edu> Assisted-by: ChatGPT:gpt-5.6-terra Signed-off-by: Priya Bala Govindasamy<pgovind2@uci.edu> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b5e4771f20a37fdf19eac0824bf062dffb4e291f ]

The `TableBuilder::to_table` function adds `Hertz(c_ulong::MAX).as_khz()`
as the last frequency entry in the frequency table.
But the C API expects the last entry to have frequency set to
`CPUFREQ_TABLE_END` which is `~1u` as per include/linux/cpufreq.h.

Fix this by setting the last frequency entry to `CPUFREQ_TABLE_END`
instead of `Hertz(c_ulong::MAX).as_khz()`.

Fixes: 2207856ff0bc8d953d6e89bda70b8978c2de8bab ("rust: cpufreq: Add initial abstractions for cpufreq framework")
Reported-by: Dylan Zueck<dzueck@uci.edu>
Reported-by: Yuan Tan<ytan089@ucr.edu>
Assisted-by: ChatGPT:gpt-5.6-terra
Signed-off-by: Priya Bala Govindasamy<pgovind2@uci.edu>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: device: make lifetime on `Core` and `CoreInternal` invariant 2026-09-14T11:39:40+00:00 Gary Guo gary@garyguo.net 2026-07-13T20:14:54+00:00 5a9f8b7f11674339b3859b5889179fa8bb7d376c [ Upstream commit f7acb19abcd867e5d2e1feb6197dcc65aa3b8e45 ] Currently the lifetime on `Core` and `CoreInternal` is covariant. This means that they can be coerced into shorter living lifetimes. On `probe` function, signature has `&'bound Device<Core<'a>>`; the type's wellformness would imply `'a: 'bound` and thus the type can be coerced `&'bound Device<Core<'bound>>`, defeating the purpose of having the lifetime bound to prevent users of the `Core` type to escape the function. Fix this by making the lifetime invariant, so the coercion is impossible. The lifetime here only needs to be "branded" so it does not coerce or unify with other lifetimes, so we do not need to ensure `'bound: 'a`. This requires modifying `nova-core` which relies on this implied bound due to pre-2024 capture rule. The "use" bound can be removed if built with edition 2024. Fixes: 24799831d631 ("rust: device: make Core and CoreInternal lifetime-parameterized") Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org [ Fixup the debugfs sample to use an explicit lifetime instead of Core<'_>. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f7acb19abcd867e5d2e1feb6197dcc65aa3b8e45 ]

Currently the lifetime on `Core` and `CoreInternal` is covariant. This
means that they can be coerced into shorter living lifetimes. On `probe`
function, signature has `&'bound Device<Core<'a>>`; the type's wellformness
would imply `'a: 'bound` and thus the type can be coerced `&'bound
Device<Core<'bound>>`, defeating the purpose of having the lifetime bound
to prevent users of the `Core` type to escape the function.

Fix this by making the lifetime invariant, so the coercion is impossible.
The lifetime here only needs to be "branded" so it does not coerce or unify
with other lifetimes, so we do not need to ensure `'bound: 'a`.

This requires modifying `nova-core` which relies on this implied bound due
to pre-2024 capture rule. The "use" bound can be removed if built with
edition 2024.

Fixes: 24799831d631 ("rust: device: make Core and CoreInternal lifetime-parameterized")
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org
[ Fixup the debugfs sample to use an explicit lifetime instead of
  Core<'_>. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: drm: gpuvm: require Send + Sync for the driver's associated data 2026-09-14T11:39:27+00:00 Sami Tolvanen samitolvanen@google.com 2026-06-11T22:17:21+00:00 fb66f61a8e7529acf4db7034c3898100fdd9b318 [ Upstream commit b59ec72fec247b90dc26f17c5b1ee9f1e0fe334c ] DriverGpuVm permitted !Send/!Sync associated data on an abstraction whose handles are shared and dropped across threads: obtain() runs from many threads and the VA API performs deferred cross-thread drops. That is unsound. Require Send + Sync on the trait and its associated data so the GpuVm and UniqueRefGpuVm handle impls need no per-impl bounds. Fixes: 82b78182eacf ("rust: drm: add base GPUVM immediate mode abstraction") Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Link: https://patch.msgid.link/20260611-gpuvm-sync-send-v4-1-6c7f4ab2778a@google.com Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b59ec72fec247b90dc26f17c5b1ee9f1e0fe334c ]

DriverGpuVm permitted !Send/!Sync associated data on an abstraction whose
handles are shared and dropped across threads: obtain() runs from many
threads and the VA API performs deferred cross-thread drops. That is
unsound.

Require Send + Sync on the trait and its associated data so the GpuVm and
UniqueRefGpuVm handle impls need no per-impl bounds.

Fixes: 82b78182eacf ("rust: drm: add base GPUVM immediate mode abstraction")
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://patch.msgid.link/20260611-gpuvm-sync-send-v4-1-6c7f4ab2778a@google.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: drm: gpuvm: update DriverGpuVm for DeviceContext 2026-09-14T11:39:03+00:00 Deborah Brouwer deborah.brouwer@collabora.com 2026-06-11T00:01:26+00:00 b49e7a24cf5bdcd9dd9dc4d067f8b2623973b26d [ Upstream commit 20003c1a1fd80ae1b1742ff54297b67f7f21b77f ] Since the introduction of DeviceContext, there is no longer a single driver object type to equate with the GPUVM object type. Instead of threading DeviceContext through GPUVM, remove the strict identity between DriverGpuVm::Object and drm::Driver::Object and instead tighten the requirement that the DriverGpuVm::Object be an allocatable GEM object associated with the same DRM driver. Also, make GpuVm::new() generic over DeviceContext so it can accept a drm::Device<T::Driver, Ctx>. Fixes: 0023a1e8d01a ("rust/drm/gem: Use DeviceContext with GEM objects") Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Link: https://patch.msgid.link/20260610-gpuvm_device_context_v1-v1-1-01a890b17448@collabora.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 20003c1a1fd80ae1b1742ff54297b67f7f21b77f ]

Since the introduction of DeviceContext, there is no longer a single
driver object type to equate with the GPUVM object type.

Instead of threading DeviceContext through GPUVM, remove the strict
identity between DriverGpuVm::Object and drm::Driver::Object and
instead tighten the requirement that the DriverGpuVm::Object be an
allocatable GEM object associated with the same DRM driver.

Also, make GpuVm::new() generic over DeviceContext so it can accept a
drm::Device<T::Driver, Ctx>.

Fixes: 0023a1e8d01a ("rust/drm/gem: Use DeviceContext with GEM objects")
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://patch.msgid.link/20260610-gpuvm_device_context_v1-v1-1-01a890b17448@collabora.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments 2026-09-11T09:51:10+00:00 Danilo Krummrich dakr@kernel.org 2026-06-28T14:53:21+00:00 cc2bc29770b312d1caff6bcd5c4c395e64d98831 commit 68b151bc6145dea3db5598ebaf4b776cd205e395 upstream. References to dev, data, and file in the declare_drm_ioctls! macro are created via unsafe pointer dereferences, producing unbounded lifetimes. If an ioctl handler explicitly annotates its parameters with 'static, the compiler accepts this, allowing the handler to stash references that outlive the ioctl call. Fix this by adding a higher-ranked function pointer coercion that enforces the handler accepts universally quantified lifetimes: let _: for<'a> fn(&'a _, &'a mut _, &'a _) -> _ = $func; Since the handler must be coercible to a function pointer accepting any lifetime 'a, it can no longer demand 'static on any parameter. Cc: stable@vger.kernel.org Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620011346.A47D01F000E9@smtp.kernel.org/ Suggested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260628145406.2107056-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 68b151bc6145dea3db5598ebaf4b776cd205e395 upstream.

References to dev, data, and file in the declare_drm_ioctls! macro are
created via unsafe pointer dereferences, producing unbounded lifetimes.
If an ioctl handler explicitly annotates its parameters with 'static,
the compiler accepts this, allowing the handler to stash references that
outlive the ioctl call.

Fix this by adding a higher-ranked function pointer coercion that
enforces the handler accepts universally quantified lifetimes:

  let _: for<'a> fn(&'a _, &'a mut _, &'a _) -> _ = $func;

Since the handler must be coercible to a function pointer accepting any
lifetime 'a, it can no longer demand 'static on any parameter.

Cc: stable@vger.kernel.org
Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260620011346.A47D01F000E9@smtp.kernel.org/
Suggested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: num: reject Bounded::shr overshifts at build time 2026-09-07T15:37:23+00:00 Eliot Courtney ecourtney@nvidia.com 2026-09-03T11:01:33+00:00 ceab9302388b22baa11c08386f3a04315baf1593 [ Upstream commit 223aa25aee82e188ddf043a8703b16e5fdfc37d8 ] Make `shr` reject shifts of at least the type's bit width at build time, instead of panicking or masking the shift amount at runtime. [ This implies we can break the type invariant, which in turn means we can trigger UB via `Deref`, e.g.: rust_kernel: panicked at rust/kernel/num/bounded.rs:528:22: unsafe precondition(s) violated: hint::unreachable_unchecked must never be reached - Miguel ] Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Cc: stable@vger.kernel.org Fixes: c59a2d14cd24 ("rust: num: add `shr` and `shl` methods to `Bounded`") Link: https://patch.msgid.link/20260810-pramin-split-v2-2-65a00b3c7309@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 223aa25aee82e188ddf043a8703b16e5fdfc37d8 ]

Make `shr` reject shifts of at least the type's bit width at build
time, instead of panicking or masking the shift amount at runtime.

[ This implies we can break the type invariant, which in turn means
  we can trigger UB via `Deref`, e.g.:

      rust_kernel: panicked at rust/kernel/num/bounded.rs:528:22:
      unsafe precondition(s) violated: hint::unreachable_unchecked must never be reached

    - Miguel ]

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Cc: stable@vger.kernel.org
Fixes: c59a2d14cd24 ("rust: num: add `shr` and `shl` methods to `Bounded`")
Link: https://patch.msgid.link/20260810-pramin-split-v2-2-65a00b3c7309@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: num: restrict bool conversion to unsigned Bounded 2026-09-07T15:36:31+00:00 Younes Akhouayri git@younes.io 2026-08-22T08:44:47+00:00 9d9b98b396099a5ae4ba7399311e100c17704d64 commit 7dd6343fc127935425a81a8f1989907996c2868d upstream. From<bool> turns true into 1. A signed Bounded with N = 1 can hold only -1 and 0. The current implementation can therefore create a value that breaks Bounded's invariant. Deref relies on that invariant and calls unreachable_unchecked() when it is broken, so safe Rust can reach undefined behavior. The other primitive conversions require the source and destination to have the same signedness. Treat bool as an unsigned one-bit value and allow conversions between bool and Bounded only when the backing integer type is unsigned. Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type") Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/ Cc: stable@vger.kernel.org Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Younes Akhouayri <git@younes.io> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7dd6343fc127935425a81a8f1989907996c2868d upstream.

From<bool> turns true into 1. A signed Bounded with N = 1 can hold
only -1 and 0. The current implementation can therefore create a value
that breaks Bounded's invariant. Deref relies on that invariant and
calls unreachable_unchecked() when it is broken, so safe Rust can reach
undefined behavior.

The other primitive conversions require the source and destination to
have the same signedness. Treat bool as an unsigned one-bit value and
allow conversions between bool and Bounded only when the backing integer
type is unsigned.

Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type")
Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/
Cc: stable@vger.kernel.org
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Younes Akhouayri <git@younes.io>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: kernel: list: fix incorrect pop_back example comment 2026-09-07T15:36:31+00:00 Nikolai Grlica nikolai@nikolaigrlica.dev 2026-08-10T15:03:35+00:00 744794d8920e99deac63c6ddb3ddedd4c625a6f9 commit a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c upstream. The example uses pop_back(), but the accompanying comment says pop_front(). Update the comment to match the example. Signed-off-by: Nikolai Grlica <nikolai@nikolaigrlica.dev> Cc: stable@vger.kernel.org Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage") Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c upstream.

The example uses pop_back(), but the accompanying comment says
pop_front(). Update the comment to match the example.

Signed-off-by: Nikolai Grlica <nikolai@nikolaigrlica.dev>
Cc: stable@vger.kernel.org
Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage")
Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: devres: ensure revocation is complete before device finishes unbinding 2026-09-07T15:36:31+00:00 Danilo Krummrich dakr@kernel.org 2026-06-28T20:02:53+00:00 cdbbcd7c64c9d4dc8d1a47e34cb16db90fbc5a13 commit a10639966fd72fff8f7fbf3c8e733307daabd38f upstream. Now that the revocation Completion is in place, also address the symmetric case. When Devres::drop() wins the is_available swap and the devres callback loses, the callback returns to devres_release_all() without waiting. This means device unbinding can complete while Devres::drop() is still executing drop_in_place() on another CPU, which is a problem if T's destructor accesses device state. Make the synchronization bidirectional. Whichever side performs drop_in_place() signals the Completion, and the other side waits. This does not reintroduce the nested Devres deadlock fixed by commit ba268514ea14 ("rust: devres: fix race condition due to nesting"), because that deadlock was caused by drop waiting for the release callback to return (the old 'devm' Completion). Here, both sides only wait for drop_in_place() to finish, which completes within the current call chain. The Arc<Inner<T>> keeps the Inner allocation alive independently. Cc: stable@vger.kernel.org Fixes: ba268514ea14 ("rust: devres: fix race condition due to nesting") Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260628200304.2365598-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a10639966fd72fff8f7fbf3c8e733307daabd38f upstream.

Now that the revocation Completion is in place, also address the
symmetric case. When Devres::drop() wins the is_available swap and the
devres callback loses, the callback returns to devres_release_all()
without waiting. This means device unbinding can complete while
Devres::drop() is still executing drop_in_place() on another CPU, which
is a problem if T's destructor accesses device state.

Make the synchronization bidirectional. Whichever side performs
drop_in_place() signals the Completion, and the other side waits.

This does not reintroduce the nested Devres deadlock fixed by commit
ba268514ea14 ("rust: devres: fix race condition due to nesting"),
because that deadlock was caused by drop waiting for the release
callback to return (the old 'devm' Completion). Here, both sides only
wait for drop_in_place() to finish, which completes within the current
call chain. The Arc<Inner<T>> keeps the Inner allocation alive
independently.

Cc: stable@vger.kernel.org
Fixes: ba268514ea14 ("rust: devres: fix race condition due to nesting")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260628200304.2365598-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>