From: Danilo Krummrich <dakr@kernel.org>
To: Vitaly Wool <vitaly.wool@konsulko.se>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, Uladzislau Rezki <urezki@gmail.com>,
Alice Ryhl <aliceryhl@google.com>,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v4 3/4] rust: support large alignments in allocations
Date: Thu, 26 Jun 2025 19:58:27 +0200 [thread overview]
Message-ID: <aF2KQyUZRVNDPf-y@cassiopeiae> (raw)
In-Reply-To: <72365C10-D984-4BC5-A081-B058C1619D06@konsulko.se>
On Thu, Jun 26, 2025 at 06:29:24PM +0200, Vitaly Wool wrote:
>
>
> > On Jun 26, 2025, at 2:36 PM, Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Thu, Jun 26, 2025 at 10:36:42AM +0200, Vitaly Wool wrote:
> >> void * __must_check __realloc_size(2)
> >> -rust_helper_krealloc(const void *objp, size_t new_size, gfp_t flags)
> >> +rust_helper_krealloc(const void *objp, size_t new_size, unsigned long align, gfp_t flags)
> >> {
> >> return krealloc(objp, new_size, flags);
> >> }
> >>
> >> void * __must_check __realloc_size(2)
> >> -rust_helper_kvrealloc(const void *p, size_t size, gfp_t flags)
> >> +rust_helper_kvrealloc(const void *p, size_t size, unsigned long align, gfp_t flags)
> >> {
> >> return kvrealloc(p, size, flags);
> >> }
> >
> > I think you forgot to add comments explaining why we have the additional
> > discarded align argument.
> >
> > Also please keep those helpers as they are. You can write an identical inline
> > function in Rust that discards the align argument and calls bindings::krealloc,
> > etc.
> >
> > For instance:
> >
> > unsafe extern "C" fn krealloc_align(
> > ptr: *const c_void,
> > size: usize,
> > _align: c_ulong
> > flags: u32,
> > ) -> *mut c_void {
> > bindings::krealloc(ptr, size, flags)
> > }
> >
>
> Ugh. This is indeed a mistake from my side but I don’t quite agree with your variant here too.
> The thing is that the new patchset has a patch #2 which adds kvrealloc_node and realloc_node so this chunk IMO should have looked like
>
> -rust_helper_kvrealloc(const void *p, size_t size, gfp_t flags)
> +rust_helper_kvrealloc(const void *p, size_t size, unsigned long align, gfp_t flags)
> {
> - return kvrealloc(p, size, flags);
> + return kvrealloc_node(p, size, align, flags, NUMA_NO_NODE);
>
> }
No for two reasons:
1) Rust helpers are transparent wrappers for C functions / macros slipping
through bindgen. We don't add any logic to them, as you do here.
2) This patch is only about supporting large alignments for VMALLOC. There's
no need to introduce kvrealloc_node() (yet).
The only thing you want here is to keep the signature common between all realloc
functions. Hence, you want
unsafe extern "C" fn krealloc_align(
ptr: *const c_void,
size: usize,
_align: c_ulong
flags: u32,
) -> *mut c_void {
bindings::krealloc(ptr, size, flags)
}
on the Rust side of things. And in the next patch you want
unsafe extern "C" fn krealloc_node_align(
ptr: *const c_void,
size: usize,
_align: c_ulong
flags: u32,
c_int: nid,
) -> *mut c_void {
bindings::krealloc_node(ptr, size, flags, nid)
}
> …exactly like for vmalloc, see also my comment below.
>
> >> diff --git a/rust/helpers/vmalloc.c b/rust/helpers/vmalloc.c
> >> index 80d34501bbc0..4618c0b79283 100644
> >> --- a/rust/helpers/vmalloc.c
> >> +++ b/rust/helpers/vmalloc.c
> >> @@ -3,7 +3,7 @@
> >> #include <linux/vmalloc.h>
> >>
> >> void * __must_check __realloc_size(2)
> >> -rust_helper_vrealloc(const void *p, size_t size, gfp_t flags)
> >> +rust_helper_vrealloc(const void *p, size_t size, unsigned long align, gfp_t flags)
> >> {
> >> - return vrealloc(p, size, flags);
> >> + return vrealloc_node(p, size, align, flags, NUMA_NO_NODE);
> >> }
> >
> > Same here, just make this a "real" helper for vrealloc_node() and create a Rust
> > function vrealloc_align() like in the example above.
>
> Wait, why? What’s the use of vrealloc() if it doesn’t provide the align functionality that we need?
That's fine, then this should be
void * __must_check __realloc_size(2)
rust_helper_vrealloc_node(const void *p, size_t size,
unsigned long align,
gfp_t flags, int nid)
{
return vrealloc_node(p, size, align, flags, nid);
}
and on the Rust side, for this patch, you want:
unsafe extern "C" fn vrealloc_align(
ptr: *const c_void,
size: usize,
align: c_ulong
flags: u32,
c_int: nid,
) -> *mut c_void {
bindings::vrealloc_node(ptr, size, align, flags, bindings::NUMA_NO_NODE)
}
The diff between the patches may come out nicer if you do it the other way
around though, i.e. first support node IDs and then support larger alignments
than PAGE_SIZE for VMALLOC.
> >
> >> diff --git a/rust/kernel/alloc/allocator.rs b/rust/kernel/alloc/allocator.rs
> >> index aa2dfa9dca4c..a0d78c497974 100644
> >> --- a/rust/kernel/alloc/allocator.rs
> >> +++ b/rust/kernel/alloc/allocator.rs
> >> @@ -58,7 +58,7 @@ fn aligned_size(new_layout: Layout) -> usize {
> >> ///
> >> /// One of the following: `krealloc`, `vrealloc`, `kvrealloc`.
> >> struct ReallocFunc(
> >> - unsafe extern "C" fn(*const crate::ffi::c_void, usize, u32) -> *mut crate::ffi::c_void,
> >> + unsafe extern "C" fn(*const crate::ffi::c_void, usize, usize, u32) -> *mut crate::ffi::c_void,
> >
> > Should be c_ulong instead of usize.
> >
>
> Noted.
>
> >> );
> >>
> >> impl ReallocFunc {
> >> @@ -110,7 +110,7 @@ unsafe fn call(
> >> // - Those functions provide the guarantees of this function.
> >> let raw_ptr = unsafe {
> >> // If `size == 0` and `ptr != NULL` the memory behind the pointer is freed.
> >> - self.0(ptr.cast(), size, flags.0).cast()
> >> + self.0(ptr.cast(), size, layout.align(), flags.0).cast()
> >> };
> >>
> >> let ptr = if size == 0 {
> >> @@ -152,12 +152,6 @@ unsafe fn realloc(
> >> old_layout: Layout,
> >> flags: Flags,
> >> ) -> Result<NonNull<[u8]>, AllocError> {
> >> - // TODO: Support alignments larger than PAGE_SIZE.
> >> - if layout.align() > bindings::PAGE_SIZE {
> >> - pr_warn!("Vmalloc does not support alignments larger than PAGE_SIZE yet.\n");
> >> - return Err(AllocError);
> >> - }
> >> -
> >> // SAFETY: If not `None`, `ptr` is guaranteed to point to valid memory, which was previously
> >> // allocated with this `Allocator`.
> >> unsafe { ReallocFunc::VREALLOC.call(ptr, layout, old_layout, flags) }
> >> @@ -176,12 +170,6 @@ unsafe fn realloc(
> >> old_layout: Layout,
> >> flags: Flags,
> >> ) -> Result<NonNull<[u8]>, AllocError> {
> >> - // TODO: Support alignments larger than PAGE_SIZE.
> >> - if layout.align() > bindings::PAGE_SIZE {
> >> - pr_warn!("KVmalloc does not support alignments larger than PAGE_SIZE yet.\n");
> >> - return Err(AllocError);
> >> - }
> >
> > Didn't you propose to use VREALLOC if layout.align() > bindings::PAGE_SIZE?
> >
>
> I did, and this is what happens on the C side now, please see the #2 patch in series.
I'm fine doing it on the C side if the C side maintainers agree.
However, I don't see you doing it. kvrealloc_node_noprof() does not even have an
align argument AFAICS.
> I think it’s better this way because of uniformity but I don’t have a strong opinion on this.
I agree, but again, I don't think you do it yet. :)
>
> >> // SAFETY: If not `None`, `ptr` is guaranteed to point to valid memory, which was previously
> >> // allocated with this `Allocator`.
> >> unsafe { ReallocFunc::KVREALLOC.call(ptr, layout, old_layout, flags) }
> >
>
next prev parent reply other threads:[~2025-06-26 17:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 8:35 [PATCH v4 0/4] support large align and nid in Rust allocators Vitaly Wool
2025-06-26 8:36 ` [PATCHi v4 1/4] mm/vmalloc: allow to set node and align in vrealloc Vitaly Wool
2025-06-26 8:36 ` [PATCH v4 2/4] mm/slub: allow to set node and align in k[v]realloc Vitaly Wool
2025-06-26 20:53 ` Tamir Duberstein
2025-06-27 18:10 ` Vitaly Wool
2025-06-26 8:36 ` [PATCH v4 3/4] rust: support large alignments in allocations Vitaly Wool
2025-06-26 12:36 ` Danilo Krummrich
2025-06-26 16:29 ` Vitaly Wool
2025-06-26 17:58 ` Danilo Krummrich [this message]
2025-06-26 8:36 ` [PATCH v4 4/4] rust: support NUMA ids " Vitaly Wool
2025-06-26 12:40 ` Danilo Krummrich
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=aF2KQyUZRVNDPf-y@cassiopeiae \
--to=dakr@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=urezki@gmail.com \
--cc=vitaly.wool@konsulko.se \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).