[PATCH 0/2] lib/raid: replace __get_free_pages() call with kmalloc()

[PATCH 0/2] lib/raid: replace __get_free_pages() call with kmalloc()

[Mike Rapoport (Microsoft)]

This is a (tiny) part of larger work of replacing page allocator calls
with kmalloc:

Also in git:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/lib

Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
Mike Rapoport (Microsoft) (2):
      lib/raid: use kmalloc() in calibrate_xor_blocks()
      lib/raid6: use kmalloc() in raid6_select_algo()

 lib/raid/xor/xor-core.c | 5 +++--
 lib/raid6/algos.c       | 6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260520-lib-8afb92134307

Best regards,
--  
Sincerely yours,
Mike.

[PATCH 1/2] lib/raid: use kmalloc() in calibrate_xor_blocks()

[Mike Rapoport (Microsoft)]

The xor benchmark allocates an order 2 (4 pages) scratch buffer that is
used purely as a CPU-only XOR working area.

For such large allocations kmalloc() would fall back to alloc_pages() but
still kmalloc() is a better API as it does not require unnecessary
castings and may provide more debugging possibilities.

Replace __get_free_pages() call with kmalloc().

Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
 lib/raid/xor/xor-core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/raid/xor/xor-core.c b/lib/raid/xor/xor-core.c
index bd4e6e434418..50931fbf0324 100644
--- a/lib/raid/xor/xor-core.c
+++ b/lib/raid/xor/xor-core.c
@@ -8,6 +8,7 @@
 
 #include <linux/module.h>
 #include <linux/gfp.h>
+#include <linux/slab.h>
 #include <linux/raid/xor.h>
 #include <linux/jiffies.h>
 #include <linux/preempt.h>
@@ -114,7 +115,7 @@ static int __init calibrate_xor_blocks(void)
 	if (forced_template)
 		return 0;
 
-	b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
+	b1 = kmalloc(PAGE_SIZE * 4, GFP_KERNEL);
 	if (!b1) {
 		pr_warn("xor: Yikes!  No memory available.\n");
 		return -ENOMEM;
@@ -132,7 +133,7 @@ static int __init calibrate_xor_blocks(void)
 	pr_info("xor: using function: %s (%d MB/sec)\n",
 	       fastest->name, fastest->speed);
 
-	free_pages((unsigned long)b1, 2);
+	kfree(b1);
 	return 0;
 }
 

-- 
2.53.0

[PATCH 2/2] lib/raid6: use kmalloc() in raid6_select_algo()

[Mike Rapoport (Microsoft)]

raid6_select_algo() allocates an order 3 (8 pages) buffer that is used
as a scratch area for selection of the best algorithm.

For such large allocations kmalloc() would fall back to alloc_pages() but
still kmalloc() is a better API as it does not require unnecessary
castings and may provide more debugging possibilities.

Replace __get_free_pages() call with kmalloc().

Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
 lib/raid6/algos.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
index 799e0e5eac26..89e627c62e30 100644
--- a/lib/raid6/algos.c
+++ b/lib/raid6/algos.c
@@ -12,6 +12,7 @@
  */
 
 #include <linux/raid/pq.h>
+#include <linux/slab.h>
 #ifndef __KERNEL__
 #include <sys/mman.h>
 #include <stdio.h>
@@ -129,7 +130,6 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
 #endif
 
 #define RAID6_TEST_DISKS	8
-#define RAID6_TEST_DISKS_ORDER	3
 
 static inline const struct raid6_recov_calls *raid6_choose_recov(void)
 {
@@ -250,7 +250,7 @@ int __init raid6_select_algo(void)
 	int i, cycle;
 
 	/* prepare the buffer and fill it circularly with gfmul table */
-	disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
+	disk_ptr = kmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
 	if (!disk_ptr) {
 		pr_err("raid6: Yikes!  No memory available.\n");
 		return -ENOMEM;
@@ -275,7 +275,7 @@ int __init raid6_select_algo(void)
 	/* select raid recover functions */
 	rec_best = raid6_choose_recov();
 
-	free_pages((unsigned long)disk_ptr, RAID6_TEST_DISKS_ORDER);
+	kfree(disk_ptr);
 
 	return gen_best && rec_best ? 0 : -EINVAL;
 }

-- 
2.53.0

Re: [PATCH 1/2] lib/raid: use kmalloc() in calibrate_xor_blocks()

[David Laight]

On Wed, 20 May 2026 11:17:51 +0300
"Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:

> The xor benchmark allocates an order 2 (4 pages) scratch buffer that is
> used purely as a CPU-only XOR working area.
> 
> For such large allocations kmalloc() would fall back to alloc_pages() but
> still kmalloc() is a better API as it does not require unnecessary
> castings and may provide more debugging possibilities.
> 
> Replace __get_free_pages() call with kmalloc().

You might want to use kvalloc() here.
It is less likely to fail.

-- David

> 
> Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
>  lib/raid/xor/xor-core.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/raid/xor/xor-core.c b/lib/raid/xor/xor-core.c
> index bd4e6e434418..50931fbf0324 100644
> --- a/lib/raid/xor/xor-core.c
> +++ b/lib/raid/xor/xor-core.c
> @@ -8,6 +8,7 @@
>  
>  #include <linux/module.h>
>  #include <linux/gfp.h>
> +#include <linux/slab.h>
>  #include <linux/raid/xor.h>
>  #include <linux/jiffies.h>
>  #include <linux/preempt.h>
> @@ -114,7 +115,7 @@ static int __init calibrate_xor_blocks(void)
>  	if (forced_template)
>  		return 0;
>  
> -	b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
> +	b1 = kmalloc(PAGE_SIZE * 4, GFP_KERNEL);
>  	if (!b1) {
>  		pr_warn("xor: Yikes!  No memory available.\n");
>  		return -ENOMEM;
> @@ -132,7 +133,7 @@ static int __init calibrate_xor_blocks(void)
>  	pr_info("xor: using function: %s (%d MB/sec)\n",
>  	       fastest->name, fastest->speed);
>  
> -	free_pages((unsigned long)b1, 2);
> +	kfree(b1);
>  	return 0;
>  }
>  
> 

Re: [PATCH 2/2] lib/raid6: use kmalloc() in raid6_select_algo()

[David Laight]

On Wed, 20 May 2026 11:17:52 +0300
"Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:

> raid6_select_algo() allocates an order 3 (8 pages) buffer that is used
> as a scratch area for selection of the best algorithm.

Should this code really be using a 4k buffer rather than a PAGE_SIZE one?

-- David

> 
> For such large allocations kmalloc() would fall back to alloc_pages() but
> still kmalloc() is a better API as it does not require unnecessary
> castings and may provide more debugging possibilities.
> 
> Replace __get_free_pages() call with kmalloc().
> 
> Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
>  lib/raid6/algos.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
> index 799e0e5eac26..89e627c62e30 100644
> --- a/lib/raid6/algos.c
> +++ b/lib/raid6/algos.c
> @@ -12,6 +12,7 @@
>   */
>  
>  #include <linux/raid/pq.h>
> +#include <linux/slab.h>
>  #ifndef __KERNEL__
>  #include <sys/mman.h>
>  #include <stdio.h>
> @@ -129,7 +130,6 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
>  #endif
>  
>  #define RAID6_TEST_DISKS	8
> -#define RAID6_TEST_DISKS_ORDER	3
>  
>  static inline const struct raid6_recov_calls *raid6_choose_recov(void)
>  {
> @@ -250,7 +250,7 @@ int __init raid6_select_algo(void)
>  	int i, cycle;
>  
>  	/* prepare the buffer and fill it circularly with gfmul table */
> -	disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
> +	disk_ptr = kmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
>  	if (!disk_ptr) {
>  		pr_err("raid6: Yikes!  No memory available.\n");
>  		return -ENOMEM;
> @@ -275,7 +275,7 @@ int __init raid6_select_algo(void)
>  	/* select raid recover functions */
>  	rec_best = raid6_choose_recov();
>  
> -	free_pages((unsigned long)disk_ptr, RAID6_TEST_DISKS_ORDER);
> +	kfree(disk_ptr);
>  
>  	return gen_best && rec_best ? 0 : -EINVAL;
>  }
> 

Re: [PATCH 2/2] lib/raid6: use kmalloc() in raid6_select_algo()

[Mike Rapoport]

On Wed, May 20, 2026 at 02:06:57PM +0100, David Laight wrote:
> On Wed, 20 May 2026 11:17:52 +0300
> "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> 
> > raid6_select_algo() allocates an order 3 (8 pages) buffer that is used
> > as a scratch area for selection of the best algorithm.
> 
> Should this code really be using a 4k buffer rather than a PAGE_SIZE one?

Why?
 
> -- David
> 
> > 
> > For such large allocations kmalloc() would fall back to alloc_pages() but
> > still kmalloc() is a better API as it does not require unnecessary
> > castings and may provide more debugging possibilities.
> > 
> > Replace __get_free_pages() call with kmalloc().
> > 
> > Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > ---
> >  lib/raid6/algos.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
> > index 799e0e5eac26..89e627c62e30 100644
> > --- a/lib/raid6/algos.c
> > +++ b/lib/raid6/algos.c
> > @@ -12,6 +12,7 @@
> >   */
> >  
> >  #include <linux/raid/pq.h>
> > +#include <linux/slab.h>
> >  #ifndef __KERNEL__
> >  #include <sys/mman.h>
> >  #include <stdio.h>
> > @@ -129,7 +130,6 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
> >  #endif
> >  
> >  #define RAID6_TEST_DISKS	8
> > -#define RAID6_TEST_DISKS_ORDER	3
> >  
> >  static inline const struct raid6_recov_calls *raid6_choose_recov(void)
> >  {
> > @@ -250,7 +250,7 @@ int __init raid6_select_algo(void)
> >  	int i, cycle;
> >  
> >  	/* prepare the buffer and fill it circularly with gfmul table */
> > -	disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
> > +	disk_ptr = kmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
> >  	if (!disk_ptr) {
> >  		pr_err("raid6: Yikes!  No memory available.\n");
> >  		return -ENOMEM;
> > @@ -275,7 +275,7 @@ int __init raid6_select_algo(void)
> >  	/* select raid recover functions */
> >  	rec_best = raid6_choose_recov();
> >  
> > -	free_pages((unsigned long)disk_ptr, RAID6_TEST_DISKS_ORDER);
> > +	kfree(disk_ptr);
> >  
> >  	return gen_best && rec_best ? 0 : -EINVAL;
> >  }
> > 
> 
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/2] lib/raid6: use kmalloc() in raid6_select_algo()

[David Laight]

On Tue, 26 May 2026 17:38:24 +0300
Mike Rapoport <rppt@kernel.org> wrote:

> On Wed, May 20, 2026 at 02:06:57PM +0100, David Laight wrote:
> > On Wed, 20 May 2026 11:17:52 +0300
> > "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> >   
> > > raid6_select_algo() allocates an order 3 (8 pages) buffer that is used
> > > as a scratch area for selection of the best algorithm.  
> > 
> > Should this code really be using a 4k buffer rather than a PAGE_SIZE one?  
> 
> Why?

Why a PAGE_SIZE buffer at all?
The real data will either be file-system block/fragment or raid stripe sized.
Neither is directly related to the memory system page size.

This actually a valid question for pretty much all of these changes.

Most architectures use 4k pages (probably because 3-level page tables
fit nicely into a 32bit word and it gave a reasonable number of pages
for 1980s systems) but some use much larger pages; I think 64k and 256k
both get used.
(IIRC m68k hardware uses 2k pages, but Linux uses them in pairs.)
Larger pages reduce allocation costs, TLB pressure and memory overhead.
But can waste memory especially for mmap() of small files.

Most of these functions just want 'a reasonable sized buffer'.
Possibly requesting whole pages was originally cheaper.
But I also suspect people have written PAGE_SIZE as a name for 4096.
(Much the same as they forget that some systems have 256 byte cache lines.)

For these changes I think I'd at least add a note in the commit message
when nothing external relies in the size of the buffer and that it could
be changed to 4k.

-- David


>  
> > -- David
> >   
> > > 
> > > For such large allocations kmalloc() would fall back to alloc_pages() but
> > > still kmalloc() is a better API as it does not require unnecessary
> > > castings and may provide more debugging possibilities.
> > > 
> > > Replace __get_free_pages() call with kmalloc().
> > > 
> > > Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> > > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > > ---
> > >  lib/raid6/algos.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
> > > index 799e0e5eac26..89e627c62e30 100644
> > > --- a/lib/raid6/algos.c
> > > +++ b/lib/raid6/algos.c
> > > @@ -12,6 +12,7 @@
> > >   */
> > >  
> > >  #include <linux/raid/pq.h>
> > > +#include <linux/slab.h>
> > >  #ifndef __KERNEL__
> > >  #include <sys/mman.h>
> > >  #include <stdio.h>
> > > @@ -129,7 +130,6 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
> > >  #endif
> > >  
> > >  #define RAID6_TEST_DISKS	8
> > > -#define RAID6_TEST_DISKS_ORDER	3
> > >  
> > >  static inline const struct raid6_recov_calls *raid6_choose_recov(void)
> > >  {
> > > @@ -250,7 +250,7 @@ int __init raid6_select_algo(void)
> > >  	int i, cycle;
> > >  
> > >  	/* prepare the buffer and fill it circularly with gfmul table */
> > > -	disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
> > > +	disk_ptr = kmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
> > >  	if (!disk_ptr) {
> > >  		pr_err("raid6: Yikes!  No memory available.\n");
> > >  		return -ENOMEM;
> > > @@ -275,7 +275,7 @@ int __init raid6_select_algo(void)
> > >  	/* select raid recover functions */
> > >  	rec_best = raid6_choose_recov();
> > >  
> > > -	free_pages((unsigned long)disk_ptr, RAID6_TEST_DISKS_ORDER);
> > > +	kfree(disk_ptr);
> > >  
> > >  	return gen_best && rec_best ? 0 : -EINVAL;
> > >  }
> > >   
> > 
> >   
> 

Re: [PATCH 2/2] lib/raid6: use kmalloc() in raid6_select_algo()

[Mike Rapoport]

On Wed, May 27, 2026 at 09:37:20AM +0100, David Laight wrote:
> On Tue, 26 May 2026 17:38:24 +0300
> Mike Rapoport <rppt@kernel.org> wrote:
> 
> > On Wed, May 20, 2026 at 02:06:57PM +0100, David Laight wrote:
> > > On Wed, 20 May 2026 11:17:52 +0300
> > > "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> > >   
> > > > raid6_select_algo() allocates an order 3 (8 pages) buffer that is used
> > > > as a scratch area for selection of the best algorithm.  
> > > 
> > > Should this code really be using a 4k buffer rather than a PAGE_SIZE one?  
> > 
> > Why?
> 
> Why a PAGE_SIZE buffer at all?
> The real data will either be file-system block/fragment or raid stripe sized.
> Neither is directly related to the memory system page size.
> 
> This actually a valid question for pretty much all of these changes.
> 
> Most architectures use 4k pages (probably because 3-level page tables
> fit nicely into a 32bit word and it gave a reasonable number of pages
> for 1980s systems) but some use much larger pages; I think 64k and 256k
> both get used.
> (IIRC m68k hardware uses 2k pages, but Linux uses them in pairs.)
> Larger pages reduce allocation costs, TLB pressure and memory overhead.
> But can waste memory especially for mmap() of small files.
> 
> Most of these functions just want 'a reasonable sized buffer'.
> Possibly requesting whole pages was originally cheaper.
> But I also suspect people have written PAGE_SIZE as a name for 4096.
> (Much the same as they forget that some systems have 256 byte cache lines.)
> 
> For these changes I think I'd at least add a note in the commit message
> when nothing external relies in the size of the buffer and that it could
> be changed to 4k.

The changes from gfp to kmalloc are intentionally mechanical and
intentionally keep the same allocation size. 

The point of these changes is to stop using ancient and ugly gfp and change
users that need a buffer to use kmalloc().
It will also make it easier to differentiate uses that actually need the
*page* for the folio project.

What is the actual buffer size required is a completely different audit and
it's not related to API usage change.
 
> -- David

-- 
Sincerely yours,
Mike.