[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z5uzbW2j9fUBt-3H@boqun-archlinux>
Date: Thu, 30 Jan 2025 09:14:21 -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 Thu, Jan 30, 2025 at 04:43:22PM +0100, Alice Ryhl wrote:
> On Thu, Jan 30, 2025 at 4:33 PM Boqun Feng <boqun.feng@...il.com> wrote:
> >
> > 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...
>
> I added the assertion because it makes the SAFETY comment on a call to
> kernel::list::List::remove simpler. The C driver does not have the
> assertion.
>
Ok. Make sense.
> > > 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()".
>
> 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?
Regards,
Boqun
> Alice
Powered by blists - more mailing lists