linux-kernel - Re: [PATCH v3 00/10] Allocation APIs

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] [day] [month] [year] [list]

Date: Thu, 2 May 2024 00:06:57 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Zhi Wang <zhiw@...dia.com>
Cc: Wedson Almeida Filho <wedsonaf@...il.com>, rust-for-linux@...r.kernel.org, 
	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@...sung.com>, 
	Alice Ryhl <aliceryhl@...gle.com>, linux-kernel@...r.kernel.org, 
	Wedson Almeida Filho <walmeida@...rosoft.com>, John Hubbard <jhubbard@...dia.com>, Neo Jia <cjia@...dia.com>, 
	Andy Currid <acurrid@...dia.com>
Subject: Re: [PATCH v3 00/10] Allocation APIs

On Mon, Apr 8, 2024 at 8:48 AM Zhi Wang <zhiw@...dia.com> wrote:
>
> IMO, It seems the allocation flag here means GFP flags according to
> Patch 5 and I understand the benefit of introducing the flags.
>
> I am interested in the future plan. With this change, will Vec and Box
> stick to kernel memory application APIs with GFP flags in the future?
> e.g. GUP, kmalloc, those mostly allocates continuous memory for small
> objects. Is that the future for Vec and Box in kernel?
>
> Is there any plan for having vmalloc() in rust kernel? Currently, if I
> push a large object into a Vec, kernel MM will complain for sure. And
> literally Vec/Box themselves don't imply to the user that they allocate
> memory with limitations.
>
> Kernel uses different MM alloc APIs for different usages. For rust,
> should we have a different kind of "Vec/Box" or having a Vec/Box with
> different set of allocation flags that covers both GFP MM APIs and
> vmalloc()? I am curious about the plan.

Sorry Zhi, Danilo brought this message to my attention today (thanks!).

We have been trying to find the best way forward to support fallible
allocations, per-call-site flags, other kernel allocators and so on
for a long time, including discussions with upstream Rust.

At this point, after these years, I think the ideal path is to try our
best to avoid re-enabling `allocator_api` and to have perhaps our own
custom APIs/types as needed (possibly several depending on the use
case) -- please also see my reply at
https://lore.kernel.org/rust-for-linux/CANiq72=0BNw-KiURBjosLqfuUEPpjZPbRg1XMFZyobOzBt7aMA@mail.gmail.com/

Regarding this patch series, we mainly wanted to make progress on
(finally) allowing at least to use the GFP flags and also,
importantly, dropping `alloc` since we want to start supporting
several compiler versions soon.

Thank you for your feedback on this. It would be nice to hear what you
think about Danilo's approach in the other series and other possible
approaches that may not rely on `allocator_api`.

Cheers,
Miguel