linux-kernel - Re: [PATCH v2 1/2] rust: add initial scatterlist bindings

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: <DAZVUN9N4GBT.38B6BX4CN516F@nvidia.com>
Date: Mon, 30 Jun 2025 21:56:28 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Alexandre Courbot" <acourbot@...dia.com>, "Abdiel Janulgue"
 <abdiel.janulgue@...il.com>, <jgg@...pe.ca>, <lyude@...hat.com>,
 <dakr@...nel.org>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
 <alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
 <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <benno.lossin@...ton.me>,
 "Andreas Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl"
 <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>, "Valentin Obst"
 <kernel@...entinobst.de>, "open list" <linux-kernel@...r.kernel.org>,
 "Marek Szyprowski" <m.szyprowski@...sung.com>, "Robin Murphy"
 <robin.murphy@....com>, <airlied@...hat.com>,
 <rust-for-linux@...r.kernel.org>, "open list:DMA MAPPING HELPERS"
 <iommu@...ts.linux.dev>, "Petr Tesarik" <petr@...arici.cz>, "Andrew Morton"
 <akpm@...ux-foundation.org>, "Herbert Xu" <herbert@...dor.apana.org.au>,
 "Sui Jingfeng" <sui.jingfeng@...ux.dev>, "Randy Dunlap"
 <rdunlap@...radead.org>, "Michael Kelley" <mhklinux@...look.com>
Subject: Re: [PATCH v2 1/2] rust: add initial scatterlist bindings

On Mon Jun 30, 2025 at 5:34 PM JST, Alexandre Courbot wrote:
> I actually have some more comments, but I'd like to understasnd first
> why you decided to drop the typestate. If there is no good reason, I
> think I can provide a more detailed explanation about the design I had
> in mind when thinking about Lyude's usecase - basically, a two-stages
> typestate SGTable type where the first stage is unsafe, but the second
> one leverages SGTablePages and is safe. But going into that explanation
> now would be pointless if the typestate cannot be used for some reason.

After thinking some more about it, I think I can verbalize better my
expectations for this interface (and my problems with this version):

Basically, I believe we should (and can) only need unsafe methods when
using one of the constructors for a SG table. Once the SG table object
is built, nothing in the interface should need to be unsafe, and we
should have access to exactly the features that are safe to use
according to the construction-time invariants. This implies that we have
several constructors, and several types for SG tables - possibly
typestates or completely distinct types as you did in this version.

I wrote a bit of test code trying to match both the requirements of GEM
SHMEM objects (work with an already-existing `sg_table`), and of owned
SG tables ; and I *think* I got something that works by leveraging
`Borrow`. Let me clean up my code after a good night of sleep and I'll
try to elaborate a bit.