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

Zhongkun He
2025-10-13T04:04:08Z

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