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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACSyD1N0fb1H3_ssEyaAMh=2shQy-64gG_t3MqkedwfOLEExEA@mail.gmail.com>
Date: Mon, 13 Oct 2025 12:03:29 +0800
From: Zhongkun He <hezhongkun.hzk@...edance.com>
To: jbohac@...e.cz, Baoquan He <bhe@...hat.com>, David Hildenbrand <david@...hat.com>
Cc: 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

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.

We would like to discuss the feasibility and potential implications of
this approach with the community.

[1]:https://lore.kernel.org/all/20250610085327.51817-1-graf@amazon.com/

Best regards,
Zhongkun He