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: <aF2KQyUZRVNDPf-y@cassiopeiae>
Date: Thu, 26 Jun 2025 19:58:27 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Vitaly Wool <vitaly.wool@...sulko.se>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Uladzislau Rezki <urezki@...il.com>,
	Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v4 3/4] rust: support large alignments in allocations

On Thu, Jun 26, 2025 at 06:29:24PM +0200, Vitaly Wool wrote:
> 
> 
> > On Jun 26, 2025, at 2:36 PM, Danilo Krummrich <dakr@...nel.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) }
> > 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ