linux-kernel - Re: [PATCH 07/20] 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: <Zolf08nsj/rx6RXe@pollux.localdomain>
Date: Sat, 6 Jul 2024 17:16:35 +0200
From: Danilo Krummrich <dakr@...hat.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: ojeda@...nel.org, alex.gaynor@...il.com, wedsonaf@...il.com,
	boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
	a.hindborg@...sung.com, aliceryhl@...gle.com,
	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
Subject: Re: [PATCH 07/20] rust: alloc: implement `Vmalloc` allocator

On Sat, Jul 06, 2024 at 01:21:39PM +0000, Benno Lossin wrote:
> On 06.07.24 13:13, Danilo Krummrich wrote:
> > On Sat, Jul 06, 2024 at 10:41:28AM +0000, Benno Lossin wrote:
> >> On 04.07.24 19:06, Danilo Krummrich wrote:
> >>> @@ -112,6 +118,55 @@ unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 {
> >>>      }
> >>>  }
> >>>
> >>> +unsafe impl Allocator for Vmalloc {
> >>> +    unsafe fn realloc(
> >>> +        &self,
> >>> +        src: *mut u8,
> >>> +        old_size: usize,
> >>> +        layout: Layout,
> >>> +        flags: Flags,
> >>> +    ) -> Result<NonNull<[u8]>, AllocError> {
> >>> +        let mut size = aligned_size(layout);
> >>> +
> >>> +        let dst = if size == 0 {
> >>> +            // SAFETY: `src` is guaranteed to be previously allocated with this `Allocator` or NULL.
> >>> +            unsafe { bindings::vfree(src.cast()) };
> >>> +            NonNull::dangling()
> >>> +        } else if size <= old_size {
> >>> +            size = old_size;
> >>> +            NonNull::new(src).ok_or(AllocError)?
> >>> +        } else {
> >>> +            // SAFETY: `src` is guaranteed to point to valid memory with a size of at least
> >>> +            // `old_size`, which was previously allocated with this `Allocator` or NULL.
> >>> +            let dst = unsafe { bindings::__vmalloc_noprof(size as u64, flags.0) };
> >>> +
> >>> +            // Validate that we actually allocated the requested memory.
> >>> +            let dst = NonNull::new(dst.cast()).ok_or(AllocError)?;
> >>> +
> >>> +            if !src.is_null() {
> >>> +                // SAFETY: `src` is guaranteed to point to valid memory with a size of at least
> >>> +                // `old_size`; `dst` is guaranteed to point to valid memory with a size of at least
> >>> +                // `size`.
> >>> +                unsafe {
> >>> +                    core::ptr::copy_nonoverlapping(
> >>> +                        src,
> >>> +                        dst.as_ptr(),
> >>> +                        core::cmp::min(old_size, size),
> >>> +                    )
> >>> +                };
> >>> +
> >>> +                // SAFETY: `src` is guaranteed to be previously allocated with this `Allocator` or
> >>> +                // NULL.
> >>> +                unsafe { bindings::vfree(src.cast()) }
> >>> +            }
> >>> +
> >>> +            dst
> >>> +        };
> >>
> >> If we had not a single realloc, but shrink/grow/free/alloc, then we
> >> would not need these checks here, I personally would prefer that, what
> >> do you guys think?
> > 
> > Yeah, but look at `Kmalloc`, you'd have these checks in `Kmalloc`'s shrink/grow
> > functions instead, since `krealloc()` already behaves this way.
> 
> In the kmalloc case you would have different instantiations, no checks.
> IIUC for freeing you would do `krealloc(ptr, 0, flags)`.

We can't allow to shrink on a `grow` call and we can't allow to grow on a
`shrink` call, so we have to do the checks there before we call into krealloc().

Unless, we say that passing stupid arguments to `grow` can actually shrink and
vice versa, but then we can just keep `realloc`, right?

> 
> > Personally, I don't see much value in `shrink` and `grow`. I think
> > implementations end up calling into some `realloc` with either `new < old` or
> > `new > old` anyway.
> 
> I think a `resize` would make more sense. In general, splitting
> resizing, creating and freeing makes sense to me.

Please see the other mail thread.

> 
> ---
> Cheers,
> Benno
>