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 for Android: free password hash cracker in your pocket

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

Message-ID: <676ac763-cd23-4077-815f-8eaa9bc960fb@gmail.com>
Date: Mon, 4 Aug 2025 11:56:53 +0300
From: Abdiel Janulgue <abdiel.janulgue@...il.com>
To: Alexandre Courbot <acourbot@...dia.com>, dakr@...nel.org, jgg@...pe.ca,
 lyude@...hat.com
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 <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

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.

Regars,
Abdiel