[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251202-binder-shrink-unspin-v1-1-263efb9ad625@google.com>
Date: Tue, 02 Dec 2025 11:24:24 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Carlos Llamas <cmllamas@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
"Arve Hjønnevåg" <arve@...roid.com>, Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>,
Joel Fernandes <joelagnelf@...dia.com>, Christian Brauner <brauner@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
"Björn Roy Baron" <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org, stable@...r.kernel.org,
Alice Ryhl <aliceryhl@...gle.com>
Subject: [PATCH] rust_binder: remove spin_lock() in rust_shrink_free_page()
When forward-porting Rust Binder to 6.18, I neglected to take commit
fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into
account, and apparently I did not end up running the shrinker callback
when I sanity tested the driver before submission. This leads to crashes
like the following:
============================================
WARNING: possible recursive locking detected
6.18.0-mainline-maybe-dirty #1 Tainted: G IO
--------------------------------------------
kswapd0/68 is trying to acquire lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230
but task is already holding lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&l->lock);
lock(&l->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kswapd0/68:
#0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160
#1: ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
#2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230
To fix this, remove the spin_lock() call from rust_shrink_free_page().
Cc: stable@...r.kernel.org
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
---
drivers/android/binder/page_range.rs | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/android/binder/page_range.rs b/drivers/android/binder/page_range.rs
index 9379038f61f513c51ebed6c7e7b6fde32e5b8d06..fdd97112ef5c8b2341e498dc3567b659f05e3fd7 100644
--- a/drivers/android/binder/page_range.rs
+++ b/drivers/android/binder/page_range.rs
@@ -727,8 +727,5 @@ fn drop(self: Pin<&mut Self>) {
drop(mm);
drop(page);
- // SAFETY: We just unlocked the lru lock, but it should be locked when we return.
- unsafe { bindings::spin_lock(&raw mut (*lru).lock) };
-
LRU_REMOVED_ENTRY
}
---
base-commit: 82d12088c297fa1cef670e1718b3d24f414c23f7
change-id: 20251202-binder-shrink-unspin-1ee9872cc2ed
Best regards,
--
Alice Ryhl <aliceryhl@...gle.com>
Powered by blists - more mailing lists