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

[Daniel Almeida <daniel.almeida@collabora.com>]

> On 26 Aug 2025, at 16:13, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> 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:
>>> +	
>>> +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?

I think we're both saying the same thing, but the wording I suggested is more
straight-forward IMHO because:

a) Being able to send a &T safely is the definition of Sync,
b) When you say:

> "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 think it _implies_ that it is valid for multiple &T to be accessed
concurrently from different tasks, and that it's therefore safe to send a &T to
another task, but it doesn't spell it out. It's up to readers to then make that
logical connection themselves.

While I do agree that only 2) actually demands a more elaborate justification,
it's simpler to just rephrase the current safety comment with:

// SAFETY: `SGEntry` has no interior mutability, so it is safe to send a shared
// reference to other tasks.

or, more verbosely:

// SAFETY: It is not possible to mutate a `SGEntry` through a shared reference,
// so it is safe to send a &SGEntry to another task.

Or any variation of the wording above.

In any case, I agree that this is splitting hairs a bit and I have nothing
against keeping it as-is, I just thought it be a tad clearer :)

— Daniel