linux-kernel - Re: [PATCH v3 06/25] rust: alloc: implement `Vmalloc` allocator

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: <ZrAVagw5Wy5p0sXj@boqun-archlinux>
Date: Sun, 4 Aug 2024 16:57:30 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: ojeda@...nel.org, alex.gaynor@...il.com, wedsonaf@...il.com,
	gary@...yguo.net, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
	a.hindborg@...sung.com, aliceryhl@...gle.com,
	akpm@...ux-foundation.org, daniel.almeida@...labora.com,
	faith.ekstrand@...labora.com, boris.brezillon@...labora.com,
	lina@...hilina.net, mcanal@...lia.com, zhiw@...dia.com,
	acurrid@...dia.com, cjia@...dia.com, jhubbard@...dia.com,
	airlied@...hat.com, ajanulgu@...hat.com, lyude@...hat.com,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
	linux-mm@...ck.org, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH v3 06/25] rust: alloc: implement `Vmalloc` allocator

On Sun, Aug 04, 2024 at 07:39:52PM +0200, Danilo Krummrich wrote:
[...]
> > > > > +unsafe impl Allocator for Vmalloc {
> > > > > +    unsafe fn realloc(
> > > > > +        ptr: Option<NonNull<u8>>,
> > > > > +        layout: Layout,
> > > > > +        flags: Flags,
> > > > > +    ) -> Result<NonNull<[u8]>, AllocError> {
> > > > > +        let realloc = ReallocFunc::vrealloc();
> > > > > +
> > > > 
> > > > IIUC, vrealloc() calls __vmalloc_noprof() in allocation case, that is
> > > > calling __vmalloc_node_noprof() with align=1. In such a case, how would
> > > > vmalloc() guarantee the allocated memory is aligned to layout.align()?
> > > 
> > > True, good catch. I thought of this a while ago and then forgot to fix it.
> > 
> > Just for clarification, we're always PAGE_SIZE aligned (guaranteed by
> > __alloc_vmap_area()), which probably would always be sufficient. That's why I
> > didn't gave it too much attention in the first place and then forgot about it.
> > 
> > However, we indeed do not honor layout.align() if it's larger than PAGE_SIZE.
> 
> Another note on that:
> 
> My plan for this series was to just fail allocation for alignment requests
> larger than PAGE_SIZE. And, if required, address larger alignments in a later

Yeah, this sounds reasonable.

> series, since this one is probably big enough already.
> 
> However, for `Vmalloc` we could support it right away, since it's trivial. For
> `KVmalloc` though it requires a bit more effort.
> 

Could you elaborate why it requires a bit more effort? Because
kvrealloc() and kvmalloc() in C don't have a way to specify alignment
requirement? If so, I think a solution to that would be just providing
the K-or-V switch in Rust code, i.e. just `Vmalloc` and `Kmalloc` to
implement `KVmalloc`, which I don't think is a bad idea.

Regards,
Boqun

> For consistancy it would probably be better to support alignments larger than
> PAGE_SIZE either for `Vmalloc` and `KVmalloc` or neither of those though.
> 
> My personal tendency goes a bit more into the direction of picking consistancy.
> 
> Any other opinions?
> 
[...]