Re: [PATCH v4 01/11] rust: xarray: minor formatting fixes

[Andreas Hindborg <a.hindborg@kernel.org>]

<sashiko-bot@kernel.org> writes:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] `Guard::store` temporarily drops the exclusive lock, violating `Guard` mutual exclusion semantics.
> --
>
> commit dd1e562319819f32e9d1d6de7db886673c5422d7
> Author: Andreas Hindborg <a.hindborg@kernel.org>
>
> rust: xarray: minor formatting fixes
>
> Fix formatting in xarray module to comply with kernel coding guidelines.
>
>> diff --git a/rust/kernel/xarray.rs b/rust/kernel/xarray.rs
>> index 46e5f43223fe8..b80fb7a262d0c 100644
>> --- a/rust/kernel/xarray.rs
>> +++ b/rust/kernel/xarray.rs
>
> [ ... ]
>
>> @@ -44,7 +63,10 @@
>>  /// *guard.get_mut(0).unwrap() = 0xffff;
>>  /// assert_eq!(guard.get(0).copied(), Some(0xffff));
>>  ///
>> -/// assert_eq!(guard.store(0, beef, GFP_KERNEL)?.as_deref().copied(), Some(0xffff));
>> +/// assert_eq!(
>> +///     guard.store(0, beef, GFP_KERNEL)?.as_deref().copied(),
>> +///     Some(0xffff)
>> +/// );
>
> [Severity: High]
> This isn't a bug introduced by this patch, but since Guard::store calls
> __xa_store which explicitly drops the xa_lock to allocate memory if called
> with blocking flags (like GFP_KERNEL here), doesn't this violate the expected
> mutual exclusion guarantee of the Guard?
>
> In Rust, a lock guard is fundamentally expected to provide strict, continuous
> mutual exclusion for its entire lifetime. Temporarily releasing the lock while
> a Guard is held breaks this invariant. Any caller relying on the Guard to
> ensure atomicity (such as check-and-update patterns) will be exposed to silent
> Time-Of-Check to Time-Of-Use (TOCTOU) race conditions, as other threads can
> mutate the array while the lock is dropped.

Should we rename `Guard` to something else to clarify this, or do you
think it is enough with added documentation on `Guard`?


Best regards,
Andreas Hindborg