linux-kernel - Re: [External] Re: [PATCH v5 0/5] kdump: crashkernel reservation from CMA

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] [day] [month] [year] [list]

Message-ID: <CACSyD1M1AEbww_07KPd_AAv9RV--XsUOChGE5O+HM5CV+J5=WQ@mail.gmail.com>
Date: Tue, 14 Oct 2025 15:36:54 +0800
From: Zhongkun He <hezhongkun.hzk@...edance.com>
To: David Hildenbrand <david@...hat.com>
Cc: jbohac@...e.cz, Baoquan He <bhe@...hat.com>, kas@...nel.org, riel@...riel.com, 
	vbabka@...e.cz, nphamcs@...il.com, Vivek Goyal <vgoyal@...hat.com>, 
	Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org, akpm@...ux-foundation.org, 
	Philipp Rudo <prudo@...hat.com>, Donald Dutile <ddutile@...hat.com>, Pingfan Liu <piliu@...hat.com>, 
	Tao Liu <ltao@...hat.com>, linux-kernel@...r.kernel.org, 
	Michal Hocko <mhocko@...e.cz>, Muchun Song <muchun.song@...ux.dev>
Subject: Re: [External] Re: [PATCH v5 0/5] kdump: crashkernel reservation from CMA

On Mon, Oct 13, 2025 at 4:01 PM David Hildenbrand <david@...hat.com> wrote:
>
> On 13.10.25 06:03, Zhongkun He wrote:
> > Hi folks,
> >
> > We’re encountering the same issue that this patch series aims to address,
> > and we also planned to leverage CMA to solve it. However, some implementation
> > details on our side may differ, so we’d like to discuss our proposed approach we
> > have tried in this thread.
> >
> > 1. Register a dedicated CMA area for kexec kernel use
> > Introduce a dedicated CMA region (e.g., kexec_cma) and allocate the control
> > code page and crash segments from this area via cma_alloc. Pages for a
> > normal kexec kernel can also be allocated from this region [1].
> >
> > 2. Keep crashkernel=xx unchanged (register CMA)
> > We introduced a flag in the kexec syscall to dynamically enable
> > or disable memory reuse without system reboot. For example, with
> > crashkernel=500M (a 500M cma region), cma_alloc may use 100M for the
> > kernel,initrd and others data. This region could then be reused for the current
> > kernel if the reuse flag is set in the syscall, or left unused for dumping user
> > pages in case of a crash.
> >
> > 3. Keep this CMA region inactive by default
> > The CMA region should remain inactive until kexec is enabled with the reuse flag
> > (or fully reused when the kdump service is not enabled). It can then
> > be activated for
> > use by the current kernel.
> >
> > 4. Introduce a new migratetype KEXEC_CMA
> > Similar to the existing CMA type, this would be used to:
> > 1)Prevent page allocation from this zone for get_user_pages (GUP).
> > 2)Handle page migration correctly when pages are pinned after allocation.
>

Hi David,

> It will be hard to get something like that in for the purpose of kdump.
> Further, I'm afraid it might open up a can of worms of "migration
> temporarily failed" -> GUP failed issues for some workloads.
>
> So I assume this might currently not be the best way to move forward.

Got it, thanks.

>
> One alternative would be using GCMA [1] in the current design. The CMA
> memory would not be exposed to the buddy, but can still be used as a
> cache for clean file pages. Pinning etc. is not a problem in that context.
>
> Of course, the more we limit the usage of that region, the less
> versatile it is.

Yes, I agree.  I’ve already noticed GCMA, and I hope it can be merged upstream
in a more lightweight manner.

>
> [1] https://lkml.kernel.org/r/20251010011951.2136980-1-surenb@google.com
>
> --
> Cheers
>
> David / dhildenb
>