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: <Z6IohVx6DEV4a6cK@Mac.home>
Date: Tue, 4 Feb 2025 06:47:33 -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

On Tue, Feb 04, 2025 at 02:39:33PM +0100, Alice Ryhl wrote:
[...]
> > > > 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()".
> > >
> > > The usual name for this operation in userspace is "mutex".
> > > https://docs.rs/lock_api/0.4.12/lock_api/struct.MutexGuard.html#method.mutex
> > >
> > > But since our code is generic over many lock types, I went for "lock".
> > > But I guess it could make sense to rename it.
> > >
> >
> > Got it. The good thing about the naming of lock_api is that the name
> > "mutex" is not used for other purpose, while "lock" is a bit different.
> >
> > > > 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>)
> > >
> > > I guess, though there is precedent for having a method that gets the
> > > underlying lock, so I think it makes sense. If we had an assertion, it
> >
> > I don't disagree, but I just feel we should be careful about introducing
> > two "lock()" that one is an operation and the other is an accessor.
> >
> > > would probably take an &Lock<T,B>.
> > >
> >
> > How about:
> >
> >     impl<T, B: Backend> Lock<T, B> {
> >         pub fn assert_held_then<O>(
> >             &self, proof: &Guard<'_, T, B>, f: FnOnce() -> O
> >         ) -> O {
> >             <assert `proof` is associated with `&self`>
> >             f()
> >         }
> >     }
> >
> > In this way, not only we can assert the correct lock is held, but we can
> > also guarantee `f()` is called with the lock held. Thoughts?
> 
> I need mutable access to the guard during the function, though? I
> don't think a closure is helpful in this case.
> 
> How about I rename to `lock_ref()` instead?
> 

That would work for me, thanks!

Regards,
Boqun

> Alice