linux-kernel - Re: [PATCH v2] arm64: kexec: Add support for crashkernel CMA reservation

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: <aXnV8HBOzTTWBbsI@kernel.org>
Date: Wed, 28 Jan 2026 11:25:04 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Jinjie Ruan <ruanjinjie@...wei.com>
Cc: ardb@...nel.org, leitao@...ian.org, corbet@....net,
	catalin.marinas@....com, will@...nel.org, akpm@...ux-foundation.org,
	bp@...en8.de, mingo@...nel.org, pawan.kumar.gupta@...ux.intel.com,
	feng.tang@...ux.alibaba.com, kees@...nel.org, elver@...gle.com,
	arnd@...db.de, fvdl@...gle.com, lirongqing@...du.com,
	bhelgaas@...gle.com, bhe@...hat.com, dave.hansen@...ux.intel.com,
	cfsworks@...il.com, osandov@...com, sourabhjain@...ux.ibm.com,
	jbohac@...e.cz, ryan.roberts@....com, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2] arm64: kexec: Add support for crashkernel CMA
 reservation

On Wed, Jan 28, 2026 at 05:10:15PM +0800, Jinjie Ruan wrote:
> 
> 
> On 2026/1/28 16:31, Mike Rapoport wrote:
> > On Mon, Jan 26, 2026 at 04:13:34PM +0800, Jinjie Ruan wrote:
> >> Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the
> >> crashkernel= command line option") and commit ab475510e042 ("kdump:
> >> implement reserve_crashkernel_cma") added CMA support for kdump
> >> crashkernel reservation.
> >>
> >> Crash kernel memory reservation wastes production resources if too
> >> large, risks kdump failure if too small, and faces allocation difficulties
> >> on fragmented systems due to contiguous block constraints. The new
> >> CMA-based crashkernel reservation scheme splits the "large fixed
> >> reservation" into a "small fixed region + large CMA dynamic region": the
> >> CMA memory is available to userspace during normal operation to avoid
> >> waste, and is reclaimed for kdump upon crash—saving memory while
> >> improving reliability.
> >>
> >> So extend crashkernel CMA reservation support to arm64. The following
> >> changes are made to enable CMA reservation:
> >>
> >> - Parse and obtain the CMA reservation size along with other crashkernel
> >>   parameters.
> >> - Call reserve_crashkernel_cma() to allocate the CMA region for kdump.
> >> - Include the CMA-reserved ranges for kdump kernel to use.
> >> - Exclude the CMA-reserved ranges from the crash kernel memory to
> >>   prevent them from being exported through /proc/vmcore.
> >>
> >> Update kernel-parameters.txt to document CMA support for crashkernel on
> >> arm64 architecture.
> > 
> > I'm looking at this and at almost identical patch for riscv 
> > https://lore.kernel.org/all/20260126080738.696723-1-ruanjinjie@huawei.com
> > and it feels wrong that we have duplicate the code that excludes cma
> > ranges.
> > CMA ranges are known to the crash_core and I don't see why we cannot
> > exclude them there.
> 
> Youa are right, x86 and powerpc has similar implementations that
> excludes crashkernel cma ranges.
> 
> x86 [1]
> 
> +	for (i = 0; i < crashk_cma_cnt; ++i) {
> +		ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
> +					      crashk_cma_ranges[i].end);
> +		if (ret)
> +			return ret;
> +	}

So if this loop was in crash_prepare_elf64_headers() it would work for
arm64, riscv and x86, right?

> +
> +	return 0;
> 
> But powerpc [2] is a little different which uses a wrapper for
> crash_exclude_mem_range() and more check and realloc_mem_ranges().
> 
> +	for (i = 0; i < crashk_cma_cnt; ++i) {
> +		ret = crash_exclude_mem_range_guarded(mem_ranges,
> crashk_cma_ranges[i].start,
> +					      crashk_cma_ranges[i].end);
> +		if (ret)
> +			goto out;
> +	}

As for powerpc crash_exclude_mem_range_guarded() could only check if
mem_ranges is large enough and reallocate and then actual exclusion in
crash_prepare_elf64_headers() should also work.

> [1]: https://lore.kernel.org/all/ZWEAWMJtesa3O9M5@dwarf.suse.cz/
> [2]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b4a96ab50f368afc2360ff539a20254ca2c9a889

-- 
Sincerely yours,
Mike.