linux-kernel - Re: [PATCH v3 1/2] rust: add initial scatterlist abstraction

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: <20250805154222.GS26511@ziepe.ca>
Date: Tue, 5 Aug 2025 12:42:22 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Abdiel Janulgue <abdiel.janulgue@...il.com>
Cc: Alexandre Courbot <acourbot@...dia.com>, dakr@...nel.org,
	lyude@...hat.com, 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 <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Tamir Duberstein <tamird@...il.com>,
	FUJITA Tomonori <fujita.tomonori@...il.com>,
	open list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Caleb Sander Mateos <csander@...estorage.com>,
	Petr Tesarik <petr@...arici.cz>,
	Sui Jingfeng <sui.jingfeng@...ux.dev>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Robin Murphy <robin.murphy@....com>, airlied@...hat.com,
	"open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>,
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v3 1/2] rust: add initial scatterlist abstraction

On Mon, Aug 04, 2025 at 11:56:53AM +0300, Abdiel Janulgue wrote:
> Hi,
> 
> On 24/07/2025 08:40, Alexandre Courbot wrote:
> > 
> > I see a few issues with the `Item` type here.
> > 
> > The first one is that `Page` can only be created by allocating a new
> > page from scratch using `Page::alloc_page`. This doesn't cover the cases
> > where we want to map memory that is now allocated through this
> > mechanism, e.g. when mapping a `VVec`. So I think we have no choice but
> > return `*mut bindings::page`s.
> > 
> Just commenting on this bit, still going through the others one by one.
> Anyways, there is already existing code I'm working on that should be able
> to extend Page that are not allocated by it's constructor (e.g. those coming
> from vmalloc_to_page). I think's it's safe at least to not expose the raw
> pointers here if we can? Just a thought.

I would try not to expose vmalloc_to_page() to safe rust.

alloc_page() at least gives you a refcounted page with a sensible
refcount based lifecycle, vmalloc_to_page() gives you something that
is not refcountable at all and has a lifetime bound to the vmalloc.

They may both be struct page in C but for rust they have very
different rules and probably types.

If you want kmalloc/vmalloc to get into a scatterlist you should have
APIs to go directly from void * and into the scatterlist, and also
link the scatterlist to the lifetime of the original allocation.

Jason