From: Alice Ryhl <aliceryhl@google.com>
To: stable@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>,
Danilo Krummrich <dakr@kernel.org>
Cc: "Alexandre Courbot" <acourbot@nvidia.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Benno Lossin" <lossin@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Gary Guo" <gary@garyguo.net>,
"Markus Probst" <markus.probst@posteo.de>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
"Alice Ryhl" <aliceryhl@google.com>
Subject: [PATCH 6.18.y 4/5] rust: devres: ensure revocation is complete before device finishes unbinding
Date: Mon, 05 Oct 2026 09:47:29 +0000 [thread overview]
Message-ID: <20261005-devres-6-18-backport-v1-4-06dcf0e592d5@google.com> (raw)
In-Reply-To: <20261005-devres-6-18-backport-v1-0-06dcf0e592d5@google.com>
From: Danilo Krummrich <dakr@kernel.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: Alice Ryhl <aliceryhl@google.com>
---
rust/kernel/devres.rs | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/rust/kernel/devres.rs b/rust/kernel/devres.rs
index 02916f80db5a..fc0d8b2cb7b2 100644
--- a/rust/kernel/devres.rs
+++ b/rust/kernel/devres.rs
@@ -173,6 +173,11 @@ fn data(&self) -> &Revocable<T> {
if inner.data.revoke() {
inner.revocation.complete_all();
+ } else {
+ // Devres::drop() is concurrently revoking; wait for it to finish `drop_in_place()`
+ // before returning to `devres_release_all()`, ensuring `T` is fully torn down before
+ // the device finishes unbinding.
+ inner.revocation.wait_for_completion();
}
}
@@ -261,6 +266,8 @@ fn drop(&mut self) {
// SAFETY: When `drop` runs, it is guaranteed that nobody is accessing the revocable data
// anymore, hence it is safe not to wait for the grace period to finish.
if unsafe { self.data().revoke_nosync() } {
+ self.inner.revocation.complete_all();
+
// We revoked `self.data` before the devres action did, hence try to remove it.
if self.remove_action() {
// SAFETY: In `Self::new` we have taken an additional reference count of `self.inner`
--
2.56.0.360.g66cac248cb-goog
next prev parent reply other threads:[~2026-10-05 9:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 9:47 [PATCH 6.18.y 0/5] Four Rust Devres fixes Alice Ryhl
2026-10-05 9:47 ` [PATCH 6.18.y 1/5] rust: devres: fix race condition due to nesting Alice Ryhl
2026-10-05 9:47 ` [PATCH 6.18.y 2/5] rust: devres: add 'static bound to Devres<T> Alice Ryhl
2026-10-05 9:47 ` [PATCH 6.18.y 3/5] rust: devres: fix race between concurrent revokers Alice Ryhl
2026-10-05 9:47 ` Alice Ryhl [this message]
2026-10-05 9:47 ` [PATCH 6.18.y 5/5] rust: irq: pass RegistrationInner as cookie to request_irq Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261005-devres-6-18-backport-v1-4-06dcf0e592d5@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=markus.probst@posteo.de \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®