linux-kernel - Re: [PATCH] rust: sync: add accessor for the lock behind a given guard

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z5ubrUcSuaTtj_wW@tardis.local>
Date: Thu, 30 Jan 2025 07:33:01 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
	Waiman Long <longman@...hat.com>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: sync: add accessor for the lock behind a given
 guard

Hi Alice,

The patch looks reasonable to me, however...

On Thu, Jan 30, 2025 at 11:39:32AM +0000, Alice Ryhl wrote:
> Binder has some methods where the caller provides a lock guard, and
> Binder needs to be able to assert that the guard is associated with the
> right lock. To enable this, add an accessor to obtain a reference to the
> underlying lock that you can pass to `ptr::eq`.
> 

... could you provide more details on this usage, for example, why do
you need the assertion, is it for debug purposes? Does the current C
code have the same or similar logic? Besides...

> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> ---
>  rust/kernel/sync/lock.rs | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
> index 41dcddac69e2..681d67275b49 100644
> --- a/rust/kernel/sync/lock.rs
> +++ b/rust/kernel/sync/lock.rs
> @@ -169,7 +169,12 @@ pub struct Guard<'a, T: ?Sized, B: Backend> {
>  // SAFETY: `Guard` is sync when the data protected by the lock is also sync.
>  unsafe impl<T: Sync + ?Sized, B: Backend> Sync for Guard<'_, T, B> {}
>  
> -impl<T: ?Sized, B: Backend> Guard<'_, T, B> {
> +impl<'a, T: ?Sized, B: Backend> Guard<'a, T, B> {
> +    /// Returns the lock that this guard originates from.
> +    pub fn lock(&self) -> &'a Lock<T, B> {

How about we name this as `lock_ref()` or something else, because
`lock()` itself is already used by `Lock` for the lock *operation*, and
this is just an accessor, I would like we don't confuse code readers
when they see code like "let b = a.lock()". Moreover, if the only usage
of this is for asserting the right lock, maybe we can instead add an:

    pub fn assert_lock_associated(&self, lock_ptr: *const Lock<T, B>)

Regards,
Boqun

> +        self.lock
> +    }
> +
>      pub(crate) fn do_unlocked<U>(&mut self, cb: impl FnOnce() -> U) -> U {
>          // SAFETY: The caller owns the lock, so it is safe to unlock it.
>          unsafe { B::unlock(self.lock.state.get(), &self.state) };
> 
> ---
> base-commit: ceff0757f5dafb5be5205988171809c877b1d3e3
> change-id: 20250130-guard-get-lock-dd5452793d9a
> 
> Best regards,
> -- 
> Alice Ryhl <aliceryhl@...gle.com>
>