linux-kernel - [PATCH] rust_binder: move BC_FREE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251029-binder-bcfreebuf-option-v1-1-4d282be0439f@google.com>
Date: Wed, 29 Oct 2025 11:50:58 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Carlos Llamas <cmllamas@...gle.com>
Cc: "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>, Suren Baghdasaryan <surenb@...gle.com>, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, Alice Ryhl <aliceryhl@...gle.com>
Subject: [PATCH] rust_binder: move BC_FREE_BUFFER drop inside if statement

When looking at flamegraphs, there is a pretty large entry for the
function call drop_in_place::<Option<Allocation>> which in turn calls
drop_in_place::<Allocation>. Combined with the looper_need_return
condition, this means that the generated code looks like this:

	if let Some(buffer) = buffer {
	    if buffer.looper_need_return_on_free() {
	        self.inner.lock().looper_need_return = true;
	    }
	}
	drop_in_place::<Option<Allocation>>() { // not inlined
	    if let Some(buffer) = buffer {
	    	drop_in_place::<Allocation>(buffer);
	    }
	}

This kind of situation where you check X and then check X again is
normally optimized into a single condition, but in this case due to the
non-inlined function call to drop_in_place::<Option<Allocation>>, that
optimization does not happen.

Furthermore, the drop_in_place::<Allocation> call is only two-thirds of
the drop_in_place::<Option<Allocation>> call in the flamegraph. This
indicates that this double condition is not performing well. Also, last
time I looked at Binder perf, I remember finding that the destructor of
Allocation was involved with many branch mispredictions.

Thus, change this code to look like this:

	if let Some(buffer) = buffer {
	    if buffer.looper_need_return_on_free() {
	        self.inner.lock().looper_need_return = true;
	    }
	    drop_in_place::<Allocation>(buffer);
	}

by dropping the Allocation directly. Flamegraphs confirm that the
drop_in_place::<Option<Allocation>> call disappears from this change.

Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
---
 drivers/android/binder/thread.rs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/android/binder/thread.rs b/drivers/android/binder/thread.rs
index 7e34ccd394f8049bab88562ffb4601739aea670a..1a8e6fdc0dc42369ee078e720aa02b2554fb7332 100644
--- a/drivers/android/binder/thread.rs
+++ b/drivers/android/binder/thread.rs
@@ -1323,12 +1323,12 @@ fn write(self: &Arc<Self>, req: &mut BinderWriteRead) -> Result {
                 }
                 BC_FREE_BUFFER => {
                     let buffer = self.process.buffer_get(reader.read()?);
-                    if let Some(buffer) = &buffer {
+                    if let Some(buffer) = buffer {
                         if buffer.looper_need_return_on_free() {
                             self.inner.lock().looper_need_return = true;
                         }
+                        drop(buffer);
                     }
-                    drop(buffer);
                 }
                 BC_INCREFS => {
                     self.process

---
base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada
change-id: 20251029-binder-bcfreebuf-option-35276027ce11

Best regards,
-- 
Alice Ryhl <aliceryhl@...gle.com>