Re: [PATCH] rust: sync: lock: Add an example for Guard::lock_ref()

[Benno Lossin]

On 24.02.25 12:15, Andreas Hindborg wrote:
> "Benno Lossin" <benno.lossin@xxxxxxxxx> writes:
> 
>> On 24.02.25 09:08, Andreas Hindborg wrote:
>>> Boqun Feng <boqun.feng@xxxxxxxxx> writes:
>>>
>>>> To provide examples on usage of `Guard::lock_ref()` along with the unit
>>>> test, an "assert a lock is held by a guard" example is added.
>>>>
>>>> Signed-off-by: Boqun Feng <boqun.feng@xxxxxxxxx>
>>>> ---
>>>> This depends on Alice's patch:
>>>>
>>>> 	https://lore.kernel.org/all/20250130-guard-get-lock-v1-1-8ed87899920a@xxxxxxxxxx/
>>>>
>>>> I'm also OK to fold this in if Alice thinks it's fine.
>>>>
>>>>  rust/kernel/sync/lock.rs | 24 ++++++++++++++++++++++++
>>>>  1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
>>>> index 3701fac6ebf6..6d868e35b0a3 100644
>>>> --- a/rust/kernel/sync/lock.rs
>>>> +++ b/rust/kernel/sync/lock.rs
>>>> @@ -201,6 +201,30 @@ unsafe impl<T: Sync + ?Sized, B: Backend> Sync for Guard<'_, T, B> {}
>>>>
>>>>  impl<'a, T: ?Sized, B: Backend> Guard<'a, T, B> {
>>>>      /// Returns the lock that this guard originates from.
>>>> +    ///
>>>> +    /// # Examples
>>>> +    ///
>>>> +    /// The following example shows how to use [`Guard::lock_ref()`] to assert the corresponding
>>>> +    /// lock is held.
>>>> +    ///
>>>> +    /// ```
>>>> +    /// # use kernel::{new_spinlock, stack_pin_init, sync::lock::{Backend, Guard, Lock}};
>>>> +    ///
>>>> +    /// fn assert_held<T, B: Backend>(guard: &Guard<'_, T, B>, lock: &Lock<T, B>) {
>>>> +    ///     // Address-equal means the same lock.
>>>> +    ///     assert!(core::ptr::eq(guard.lock_ref(), lock));
>>>> +    /// }
>>>
>>> This seems super useful. Perhaps add this method as part of the lock api
>>> instead of just having it in the example?
>>
>> I don't think it should be an assert. Instead make it return a
>> `Result<(), ()>`. (or create better named unit error types)
> 
> No, this should not be part of usual control flow, and developers should
> not make control flow decisions based on this. It would always be an
> assertion. But you are right that `assert!` is probably not what we
> want. `debug_assert!` might be fine though.

I agree, that it shouldn't be used for driver logic, but you still might
want to warn/warn_once instead of panic (or debug_assert).

---
Cheers,
Benno