mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bradley Morgan <brads@mainlining.org>
To: Usama Arif <usama.arif@linux.dev>
Cc: 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, 04 Nov 2026 23:42:20 +0000	[thread overview]
Message-ID: <415B6D73-FB20-41A7-AB8D-E5F548003290@mainlining.org> (raw)
In-Reply-To: <20261104215237.203332-1-usama.arif@linux.dev>

On 4 November 2026 21:52:36 GMT, Usama Arif <usama.arif@linux.dev> wrote:
>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.

Hmm. No approach at the moment is the "perfect" approach so far.

>
>> 
>> > 		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!
>> 

--- Thanks!

      reply	other threads:[~2026-11-04 23:43 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   ` [PATCH] crash: keep crashkernel C MA " Usama Arif
2026-11-04 23:42     ` Bradley Morgan [this message]

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=415B6D73-FB20-41A7-AB8D-E5F548003290@mainlining.org \
    --to=brads@mainlining.org \
    --cc=akpm@linux-foundation.org \
    --cc=baoquan.he@linux.dev \
    --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 \
    --cc=usama.arif@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®