This is a (small) part of larger work of replacing page allocator calls
with kmalloc.

My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.

Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.

Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.

For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.

And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.

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

[1] https://lore.kernel.org/all/20251018093002.3660549-1-rppt@kernel.org/
[2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/

---
Mike Rapoport (Microsoft) (4):
      KVM: s390: Replace get_zeroed_page() with kzalloc() for the STHYI buffer
      KVM: s390: Replace get_zeroed_page() with kzalloc() for the STSI buffer
      KVM: s390: Replace get_zeroed_page() with kzalloc() for the GIB
      KVM: s390: Replace get_zeroed_page() with kzalloc() for sie_page2 and CMMA

 arch/s390/kvm/s390/intercept.c |  9 +++++----
 arch/s390/kvm/s390/interrupt.c |  8 ++++----
 arch/s390/kvm/s390/priv.c      | 19 ++++++++++---------
 arch/s390/kvm/s390/s390.c      | 12 ++++++------
 4 files changed, 25 insertions(+), 23 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260828-s390-kvm-2015b0d777dc

--
Sincerely yours,
Mike.

On Wed, 02 Sep 2026 09:15:12 +0300
"Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:

> This is a (small) part of larger work of replacing page allocator calls
> with kmalloc.
> 
> My initial intention a few month ago was to remove ugly casts [1], but then
> willy pointed out that Linus objected to something like this [2] and it
> looks like more than a decade old technical debt.
> 
> Largely, anything that doesn't need struct page (or a memdesc in the
> future) should just use kmalloc() or kvmalloc() to allocate memory.
> kmalloc() guarantees alignment, physical contiguity and working
> virt_to_phys() and beside nicer API that returns void * on alloc and
> doesn't require to know the allocation size on free, kmalloc() provides
> better debugging capabilities than page allocator.
> 
> Another thing is that touching these allocation sites gives the reviewers
> opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
> another size is appropriate.
> 
> For larger allocations that don't need physically contiguous memory
> kvmalloc() can be a better option that __get_free_pages() because under
> memory pressure it's is easier to allocate several order-0 pages than a
> physically contiguous chunk with the same number of pages.
> 
> And last, but not least, removing needless calls to page allocator should
> help with memdesc (aka project folio) conversion. There will be way less
> places to audit to see if the user was actually using struct page.

I have some objections to this series, but not because of what you are
trying to do (which is actually nice).

I understand that you probably wanted to touch as little code as
possible, but now since you're rewriting the allocations to use
kmalloc.... I'd like them to be converted to use the __free(kvmalloc)
system. It will make the code smaller, easier to read and understand,
less prone to future errors, etc.

In some places the whole code flow can be simplified a lot.
 
> Also in git:
> https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/s390-kvm
> 
> [1] https://lore.kernel.org/all/20251018093002.3660549-1-rppt@kernel.org/
> [2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/
> 
> ---
> Mike Rapoport (Microsoft) (4):
>       KVM: s390: Replace get_zeroed_page() with kzalloc() for the STHYI buffer
>       KVM: s390: Replace get_zeroed_page() with kzalloc() for the STSI buffer
>       KVM: s390: Replace get_zeroed_page() with kzalloc() for the GIB
>       KVM: s390: Replace get_zeroed_page() with kzalloc() for sie_page2 and CMMA
> 
>  arch/s390/kvm/s390/intercept.c |  9 +++++----
>  arch/s390/kvm/s390/interrupt.c |  8 ++++----
>  arch/s390/kvm/s390/priv.c      | 19 ++++++++++---------
>  arch/s390/kvm/s390/s390.c      | 12 ++++++------
>  4 files changed, 25 insertions(+), 23 deletions(-)
> ---
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
> change-id: 20260828-s390-kvm-2015b0d777dc
> 
> --
> Sincerely yours,
> Mike.
>

On Wed, Sep 02, 2026 at 01:06:12PM +0200, Claudio Imbrenda wrote:
> On Wed, 02 Sep 2026 09:15:12 +0300
> "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> 
> > This is a (small) part of larger work of replacing page allocator calls
> > with kmalloc.
> > 
> > My initial intention a few month ago was to remove ugly casts [1], but then
> > willy pointed out that Linus objected to something like this [2] and it
> > looks like more than a decade old technical debt.
> > 
> > Largely, anything that doesn't need struct page (or a memdesc in the
> > future) should just use kmalloc() or kvmalloc() to allocate memory.
> > kmalloc() guarantees alignment, physical contiguity and working
> > virt_to_phys() and beside nicer API that returns void * on alloc and
> > doesn't require to know the allocation size on free, kmalloc() provides
> > better debugging capabilities than page allocator.
> > 
> > Another thing is that touching these allocation sites gives the reviewers
> > opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
> > another size is appropriate.
> > 
> > For larger allocations that don't need physically contiguous memory
> > kvmalloc() can be a better option that __get_free_pages() because under
> > memory pressure it's is easier to allocate several order-0 pages than a
> > physically contiguous chunk with the same number of pages.
> > 
> > And last, but not least, removing needless calls to page allocator should
> > help with memdesc (aka project folio) conversion. There will be way less
> > places to audit to see if the user was actually using struct page.
> 
> I have some objections to this series, but not because of what you are
> trying to do (which is actually nice).
> 
> I understand that you probably wanted to touch as little code as
> possible,

Yep :)

> but now since you're rewriting the allocations to use
> kmalloc.... I'd like them to be converted to use the __free(kvmalloc)

You mean __free(kfree)? Sure, I can look into it.

> system. It will make the code smaller, easier to read and understand,
> less prone to future errors, etc.
> 
> In some places the whole code flow can be simplified a lot.

-- 
Sincerely yours,
Mike.

On Wed, 2 Sep 2026 16:17:03 +0300
Mike Rapoport <rppt@kernel.org> wrote:

> On Wed, Sep 02, 2026 at 01:06:12PM +0200, Claudio Imbrenda wrote:
> > On Wed, 02 Sep 2026 09:15:12 +0300
> > "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> >   
> > > This is a (small) part of larger work of replacing page allocator calls
> > > with kmalloc.
> > > 
> > > My initial intention a few month ago was to remove ugly casts [1], but then
> > > willy pointed out that Linus objected to something like this [2] and it
> > > looks like more than a decade old technical debt.
> > > 
> > > Largely, anything that doesn't need struct page (or a memdesc in the
> > > future) should just use kmalloc() or kvmalloc() to allocate memory.
> > > kmalloc() guarantees alignment, physical contiguity and working
> > > virt_to_phys() and beside nicer API that returns void * on alloc and
> > > doesn't require to know the allocation size on free, kmalloc() provides
> > > better debugging capabilities than page allocator.
> > > 
> > > Another thing is that touching these allocation sites gives the reviewers
> > > opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
> > > another size is appropriate.
> > > 
> > > For larger allocations that don't need physically contiguous memory
> > > kvmalloc() can be a better option that __get_free_pages() because under
> > > memory pressure it's is easier to allocate several order-0 pages than a
> > > physically contiguous chunk with the same number of pages.
> > > 
> > > And last, but not least, removing needless calls to page allocator should
> > > help with memdesc (aka project folio) conversion. There will be way less
> > > places to audit to see if the user was actually using struct page.  
> > 
> > I have some objections to this series, but not because of what you are
> > trying to do (which is actually nice).
> > 
> > I understand that you probably wanted to touch as little code as
> > possible,  
> 
> Yep :)
> 
> > but now since you're rewriting the allocations to use
> > kmalloc.... I'd like them to be converted to use the __free(kvmalloc)  
> 
> You mean __free(kfree)? Sure, I can look into it.

yep :)

> 
> > system. It will make the code smaller, easier to read and understand,
> > less prone to future errors, etc.
> > 
> > In some places the whole code flow can be simplified a lot.  
>

Hi Claudio,

On Wed, Sep 02, 2026 at 04:53:15PM +0200, Claudio Imbrenda wrote:
> On Wed, 2 Sep 2026 16:17:03 +0300
> Mike Rapoport <rppt@kernel.org> wrote:
> 
> > On Wed, Sep 02, 2026 at 01:06:12PM +0200, Claudio Imbrenda wrote:
> > > On Wed, 02 Sep 2026 09:15:12 +0300
> > > "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> > >   
> > > > This is a (small) part of larger work of replacing page allocator calls
> > > > with kmalloc.
> > > 
> > > I have some objections to this series, but not because of what you are
> > > trying to do (which is actually nice).
> > > 
> > > I understand that you probably wanted to touch as little code as
> > > possible,  
> > 
> > Yep :)
> > 
> > > but now since you're rewriting the allocations to use
> > > kmalloc.... I'd like them to be converted to use the __free(kvmalloc)  
> > 
> > You mean __free(kfree)? Sure, I can look into it.
> 
> yep :)

Well, I looked :) 

The only place where __free(kfree) is completely safe is handle_sthyi().

In all the other functions using __free(kfree) creates a mix of of goto
and cleanup helpers and cleanup docs advise against mixing them:

https://docs.kernel.org/core-api/cleanup.html

The cleanup paths are quite involved in these functions so using
__free(kfree) there is really not trivial.

-- 
Sincerely yours,
Mike.

On Thu, 3 Sep 2026 11:04:44 +0300
Mike Rapoport <rppt@kernel.org> wrote:

> Hi Claudio,
> 
> On Wed, Sep 02, 2026 at 04:53:15PM +0200, Claudio Imbrenda wrote:
> > On Wed, 2 Sep 2026 16:17:03 +0300
> > Mike Rapoport <rppt@kernel.org> wrote:
> >   
> > > On Wed, Sep 02, 2026 at 01:06:12PM +0200, Claudio Imbrenda wrote:  
> > > > On Wed, 02 Sep 2026 09:15:12 +0300
> > > > "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> > > >     
> > > > > This is a (small) part of larger work of replacing page allocator calls
> > > > > with kmalloc.  
> > > > 
> > > > I have some objections to this series, but not because of what you are
> > > > trying to do (which is actually nice).
> > > > 
> > > > I understand that you probably wanted to touch as little code as
> > > > possible,    
> > > 
> > > Yep :)
> > >   
> > > > but now since you're rewriting the allocations to use
> > > > kmalloc.... I'd like them to be converted to use the __free(kvmalloc)    
> > > 
> > > You mean __free(kfree)? Sure, I can look into it.  
> > 
> > yep :)  
> 
> Well, I looked :) 
> 
> The only place where __free(kfree) is completely safe is handle_sthyi().
> 
> In all the other functions using __free(kfree) creates a mix of of goto
> and cleanup helpers and cleanup docs advise against mixing them:
> 
> https://docs.kernel.org/core-api/cleanup.html
> 
> The cleanup paths are quite involved in these functions so using

it looked trivial when I gave it a cursory glance, hence the reason of
my original request, but... 

> __free(kfree) there is really not trivial.

... yeah, it's actually not trivial at all.


maybe refactor the first patch, and leave the rest as it is :)

On Thu, Sep 03, 2026 at 03:08:52PM +0200, Claudio Imbrenda wrote:
> > 
> > The only place where __free(kfree) is completely safe is handle_sthyi().
> > 
> > In all the other functions using __free(kfree) creates a mix of of goto
> > and cleanup helpers and cleanup docs advise against mixing them:
> > 
> > https://docs.kernel.org/core-api/cleanup.html
> > 
> > The cleanup paths are quite involved in these functions so using
> 
> it looked trivial when I gave it a cursory glance, hence the reason of
> my original request, but... 
> 
> > __free(kfree) there is really not trivial.
> 
> ... yeah, it's actually not trivial at all.
> 
> 
> maybe refactor the first patch, and leave the rest as it is :)

Yeah, that's what I've been thinking too.
And leave the rest to s390 kvm experts :)

-- 
Sincerely yours,
Mike.