From: Mike Rapoport <rppt@kernel.org>
To: Kiryl Shutsemau <kas@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
stable@vger.kernel.org
Subject: Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()
Date: Thu, 29 Oct 2026 14:40:21 +0200 [thread overview]
Message-ID: <auM-tYrdV4TJgJ6K@kernel.org> (raw)
In-Reply-To: <auM6lKGAeUI26jCj@thinkstation>
On Thu, Oct 29, 2026 at 12:27:23PM +0000, Kiryl Shutsemau wrote:
> On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote:
> > Pages of allocated CMA areas are released to the buddy allocator with
> > __free_pages(), which does not check for unaccepted memory.
> >
> > This usually works because memblock accepts the memory it allocates.
> >
> > However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
> > requested with cma=<size>@<base> are reserved with memblock_reserve() and
> > their memory is never accepted.
>
> It feels like memblock_reserve() abuse, no?
>
> crashkernel=size@base already uses memblock_phys_alloc_range() for this.
> Should the fixed and multi-range CMA paths go through the allocation API
> as well.
Fixed path already has the range, why would it use allocation APIs?
The multi-range could, but it will be several times slower and I believe
the intention was to avoid allocation APIs exactly because of that.
> --
> Kiryl Shutsemau / Kirill A. Shutemov
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2026-10-29 12:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 10:18 [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve() Mike Rapoport (Microsoft)
2026-10-29 10:18 ` [PATCH 1/2] mm/cma: accept memory of multi-range CMA areas Mike Rapoport (Microsoft)
2026-10-29 10:52 ` Gupta, Pankaj
2026-10-29 12:19 ` Mike Rapoport
2026-10-29 10:18 ` [PATCH 2/2] mm/cma: accept memory of CMA areas reserved at a fixed address Mike Rapoport (Microsoft)
2026-10-29 12:27 ` [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve() Kiryl Shutsemau
2026-10-29 12:40 ` Mike Rapoport [this message]
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=auM-tYrdV4TJgJ6K@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=kas@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.