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: <796b50c4-0824-4b9f-97f9-750f34096ed6@proton.me>
Date: Sat, 06 Jul 2024 13:21:39 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Danilo Krummrich <dakr@...hat.com>
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 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)`.

> 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.

---
Cheers,
Benno