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: <DCCLKO6HTCM8.YR8VE8PAXQTM@kernel.org>
Date: Tue, 26 Aug 2025 21:13:53 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Daniel Almeida" <daniel.almeida@...labora.com>
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 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:
>> +// 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?