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

[Alice Ryhl]

On Thu, Jan 30, 2025 at 4:33 PM Boqun Feng <boqun.feng@xxxxxxxxx> 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.

> > Signed-off-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>
> > ---
> >  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.

> 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
would probably take an &Lock<T,B>.

Alice