mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Bradley Morgan <brads@mainlining.org>
Cc: Usama Arif <usama.arif@linux.dev>,
	akpm@linux-foundation.org, baoquan.he@linux.dev,
	david@kernel.org, hannes@cmpxchg.org, hbathini@linux.ibm.com,
	jbohac@suse.cz, kas@kernel.org, kernel-team@meta.com,
	kexec@lists.infradead.org, leitao@debian.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	pasha.tatashin@soleen.com, pratyush@kernel.org, riel@surriel.com,
	rppt@kernel.org, ruirui.yang@linux.dev, shakeel.butt@linux.dev
Subject: Re: [PATCH] crash: keep crashkernel C MA pages reserved if activation fails
Date: Wed,  4 Nov 2026 13:52:36 -0800	[thread overview]
Message-ID: <20261104215237.203332-1-usama.arif@linux.dev> (raw)
In-Reply-To: <661AFDEC-B8DF-4A5B-8C58-1D39F518F068@mainlining.org>

On Wed, 04 Nov 2026 19:16:42 +0000 Bradley Morgan <brads@mainlining.org> wrote:

> On 4 November 2026 14:56:00 GMT, Usama Arif <usama.arif@linux.dev> wrote:
> >reserve_crashkernel_cma() adds each crashkernel CMA area to
> >crashk_cma_ranges[] as soon as it is declared. If the area later fails
> >activation, e.g. because movablecore= put the ZONE_MOVABLE boundary
> >inside it, cma_activate_area() releases the pages to the buddy allocator
> >as ordinary memory. The range is still handed to the crash kernel and
> >excluded from the vmcore, so kernel data that lands there is overwritten
> >by the crash kernel and missing from the dump.
> >
> >Mark the areas with cma_reserve_pages_on_error(), so that a failed
> >activation leaves the pages reserved: lost to the first kernel, but safe
> >for the crash kernel to use.
> >
> >Fixes: ab475510e042 ("kdump: implement reserve_crashkernel_cma")
> >Signed-off-by: Usama Arif <usama.arif@linux.dev>
> >---
> > kernel/crash_reserve.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >diff --git a/kernel/crash_reserve.c b/kernel/crash_reserve.c
> >index a03f0a4305a4e..a4b616ed49482 100644
> >--- a/kernel/crash_reserve.c
> >+++ b/kernel/crash_reserve.c
> >@@ -498,6 +498,7 @@ void __init reserve_crashkernel_cma(unsigned long long cma_size)
> > 			continue;
> > 		}
> > 
> >+		cma_reserve_pages_on_error(res);
> 
> You do know that this will activate under every bitmap_zalloc() failure,
> right? Is that accounted for?

Yes, that's intended. By the time cma_activate_area() runs, the range is
already in crashk_cma_ranges[], so the crash kernel will use it no matter
why activation failed. Keeping the pages reserved is the only way to make
sure the first kernel has nothing there that gets overwritten or goes
missing from the vmcore; the area then behaves like a regular
crashkernel= reservation of the same size.

fadump made the same choice; it is what cma_reserve_pages_on_error() was
added for in commit 27d121d0ec6d ("mm/cma: provide option to opt out
from exposing pages on activation failure").

The bitmap is one bit per page (32 KiB per GiB with 4K pages) and is
allocated at core_initcall, so a failure there is very unlikely.

The alternative is to give the memory back and to drop the
range from crashk_cma_ranges[] when activation fails, leaving the crash
kernel with less memory than requested. I do think that is acceptable as
well. But we do need either whats done in this patch or give the memory
back. Happy to send the alternative as v2 is everyone thinks that the
better way forward.

> 
> > 		crashk_cma_ranges[crashk_cma_cnt].start = cma_get_base(res);
> > 		crashk_cma_ranges[crashk_cma_cnt].end =
> > 			crashk_cma_ranges[crashk_cma_cnt].start +
> >
> 
> --- Thanks!
> 

  reply	other threads:[~2026-11-04 21:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 14:56 [PATCH] crash: keep crashkernel CMA " Usama Arif
2026-11-04 19:16 ` Bradley Morgan
2026-11-04 21:52   ` Usama Arif [this message]
2026-11-04 23:42     ` [PATCH] crash: keep crashkernel C MA " Bradley Morgan

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=20261104215237.203332-1-usama.arif@linux.dev \
    --to=usama.arif@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baoquan.he@linux.dev \
    --cc=brads@mainlining.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hbathini@linux.ibm.com \
    --cc=jbohac@suse.cz \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kexec@lists.infradead.org \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=ruirui.yang@linux.dev \
    --cc=shakeel.butt@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®