linux-kernel - Re: [PATCH v3 3/5] rust: scatterlist: Add abstraction for sg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <3BD5A415-CD19-4B8E-A2A3-78F60FCC863A@collabora.com>
Date: Tue, 26 Aug 2025 17:16:56 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: akpm@...ux-foundation.org,
 ojeda@...nel.org,
 alex.gaynor@...il.com,
 boqun.feng@...il.com,
 gary@...yguo.net,
 bjorn3_gh@...tonmail.com,
 lossin@...nel.org,
 a.hindborg@...nel.org,
 aliceryhl@...gle.com,
 tmgross@...ch.edu,
 abdiel.janulgue@...il.com,
 acourbot@...dia.com,
 jgg@...pe.ca,
 lyude@...hat.com,
 robin.murphy@....com,
 rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/5] rust: scatterlist: Add abstraction for sg_table



> On 26 Aug 2025, at 16:13, Danilo Krummrich <dakr@...nel.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@...nel.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