All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@redhat.com>
To: Benno Lossin <benno.lossin@proton.me>
Cc: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com,
	boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
	a.hindborg@samsung.com, aliceryhl@google.com,
	daniel.almeida@collabora.com, faith.ekstrand@collabora.com,
	boris.brezillon@collabora.com, lina@asahilina.net,
	mcanal@igalia.com, zhiw@nvidia.com, acurrid@nvidia.com,
	cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com,
	ajanulgu@redhat.com, lyude@redhat.com,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 07/20] rust: alloc: implement `Vmalloc` allocator
Date: Sat, 6 Jul 2024 17:16:35 +0200	[thread overview]
Message-ID: <Zolf08nsj/rx6RXe@pollux.localdomain> (raw)
In-Reply-To: <796b50c4-0824-4b9f-97f9-750f34096ed6@proton.me>

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
> 


  reply	other threads:[~2024-07-06 15:16 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-04 17:06 [PATCH 00/20] Generic `Allocator` support for Rust Danilo Krummrich
2024-07-04 17:06 ` [PATCH 01/20] rust: alloc: add `Allocator` trait Danilo Krummrich
2024-07-06 10:33   ` Benno Lossin
2024-07-06 11:05     ` Danilo Krummrich
2024-07-06 13:17       ` Benno Lossin
2024-07-06 15:11         ` Danilo Krummrich
2024-07-06 17:08           ` Benno Lossin
2024-07-06 18:47             ` Danilo Krummrich
2024-07-08  8:12               ` Benno Lossin
2024-07-08 23:12                 ` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 02/20] rust: alloc: separate `aligned_size` from `krealloc_aligned` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 03/20] rust: alloc: rename `KernelAllocator` to `Kmalloc` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 04/20] rust: alloc: implement `Allocator` for `Kmalloc` Danilo Krummrich
2024-07-06 10:37   ` Benno Lossin
2024-07-06 11:08     ` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 05/20] rust: alloc: add module `allocator_test` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 06/20] rust: alloc: remove `krealloc_aligned` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 07/20] rust: alloc: implement `Vmalloc` allocator Danilo Krummrich
2024-07-06 10:41   ` Benno Lossin
2024-07-06 11:13     ` Danilo Krummrich
2024-07-06 13:21       ` Benno Lossin
2024-07-06 15:16         ` Danilo Krummrich [this message]
2024-07-04 17:06 ` [PATCH 08/20] rust: alloc: implement `KVmalloc` allocator Danilo Krummrich
2024-07-04 17:06 ` [PATCH 09/20] rust: types: implement `Unique<T>` Danilo Krummrich
2024-07-06 10:59   ` Benno Lossin
2024-07-06 12:40     ` Miguel Ojeda
2024-07-06 13:37       ` Benno Lossin
2024-07-04 17:06 ` [PATCH 10/20] rust: alloc: implement `KBox` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 11/20] rust: treewide: switch to `KBox` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 12/20] rust: alloc: remove `BoxExt` extension Danilo Krummrich
2024-07-04 17:06 ` [PATCH 13/20] rust: alloc: implement `KVec` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 14/20] rust: alloc: implement `IntoIterator` for `KVec` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 15/20] rust: alloc: implement `collect` for `IntoIter` Danilo Krummrich
2024-07-04 23:27   ` Boqun Feng
2024-07-05  1:23     ` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 16/20] rust: treewide: switch to `KVec` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 17/20] rust: alloc: remove `VecExt` extension Danilo Krummrich
2024-07-04 17:06 ` [PATCH 18/20] rust: error: use `core::alloc::LayoutError` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 19/20] rust: str: test: replace `alloc::format` Danilo Krummrich
2024-07-04 17:06 ` [PATCH 20/20] kbuild: rust: remove the `alloc` crate Danilo Krummrich
2024-07-06  3:59   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zolf08nsj/rx6RXe@pollux.localdomain \
    --to=dakr@redhat.com \
    --cc=a.hindborg@samsung.com \
    --cc=acurrid@nvidia.com \
    --cc=airlied@redhat.com \
    --cc=ajanulgu@redhat.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=cjia@nvidia.com \
    --cc=daniel.almeida@collabora.com \
    --cc=faith.ekstrand@collabora.com \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=lina@asahilina.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=mcanal@igalia.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    --cc=zhiw@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.