[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260107173734.03081035.gary@garyguo.net>
Date: Wed, 7 Jan 2026 17:37:34 +0000
From: Gary Guo <gary@...yguo.net>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Boqun Feng <boqun.feng@...il.com>, Peter Zijlstra
<peterz@...radead.org>, Will Deacon <will@...nel.org>, Ingo Molnar
<mingo@...hat.com>, Waiman Long <longman@...hat.com>, Miguel Ojeda
<ojeda@...nel.org>, "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
Subject: Re: [PATCH v2] rust: sync: inline various lock related methods
On Thu, 18 Dec 2025 12:10:23 +0000
Alice Ryhl <aliceryhl@...gle.com> wrote:
> While debugging a different issue [1], I inspected a rust_binder.ko file
> and noticed the following relocation:
>
> R_AARCH64_CALL26 _RNvXNtNtNtCsdfZWD8DztAw_6kernel4sync4lock8spinlockNtB2_15SpinLockBackendNtB4_7Backend6unlock
>
> This relocation (and a similar one for lock) occurred many times
> throughout the module. That is not really useful because all this
> function does is call spin_unlock(), so what we actually want here is
> that a call to spin_unlock() dirctly is generated in favor of this
> wrapper method.
>
> Thus, mark these methods inline.
>
> Link: https://lore.kernel.org/p/20251111-binder-fix-list-remove-v1-0-8ed14a0da63d@google.com
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
Reviewed-by: Gary Guo <gary@...yguo.net>
Best,
Gary
> ---
> Changes in v2:
> - Rebased on v6.19-rc1.
> - Link to v1: https://lore.kernel.org/r/20251113-inline-lock-unlock-v1-1-1b6e8c323bcf@google.com
> ---
> rust/kernel/sync/lock.rs | 7 +++++++
> rust/kernel/sync/lock/global.rs | 2 ++
> rust/kernel/sync/lock/mutex.rs | 5 +++++
> rust/kernel/sync/lock/spinlock.rs | 5 +++++
> 4 files changed, 19 insertions(+)
Powered by blists - more mailing lists