Re: [PATCH v3 3/5] rust: scatterlist: Add abstraction for sg_table

["Danilo Krummrich" <dakr@kernel.org>]

On Tue Aug 26, 2025 at 7:40 PM CEST, Daniel Almeida wrote:
>> On 25 Aug 2025, at 10:24, Danilo Krummrich <dakr@kernel.org> wrote:
>> +// SAFETY: `SGEntry` can be accessed concurrently.
>> +unsafe impl Sync for SGEntry {}
>
> IMHO all safety comments for Sync must mention how it’s ok to send &T to
> another thread for a given T.

When we say "`T` can be accessed concurrently." it means that it is valid for
multiple &T to be accessed concurrently from different tasks.

I.e. what we care about in this case is interior mutability, where we can have
three cases:

  (1) There is no interior mutability, hence the type is Sync.

  (2) There is interior mutability, but there's also internal mechanisms taking
      care of data races, hence the type is Sync.

  (3) There is interior mutability and nothing prevents data races, hence the
      type is not Sync.

I feel like only case (2) really needs justification, because it needs to
explain how those "internal mechanisms" work.

Those abstractions do not have any interior mutability, hence I think what we
have is enough. Does that make sense?