Re: [PATCH 0/4] KVM: s390: replace page allocator calls with kzalloc()

[Mike Rapoport]

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@xxxxxxxxxx> 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.