mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] crash: keep crashkernel CMA pages reserved if activation fails
@ 2026-11-04 14:56 Usama Arif
  2026-11-04 19:16 ` Bradley Morgan
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Usama Arif @ 2026-11-04 14:56 UTC (permalink / raw)
  To: Andrew Morton, baoquan.he, rppt, pasha.tatashin, pratyush,
	ruirui.yang, jbohac, david, hbathini, leitao, kexec, linux-mm,
	linux-kernel, kas, hannes, riel, shakeel.butt, kernel-team
  Cc: Usama Arif

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);
 		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 +
-- 
2.53.0-Meta


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] crash: keep crashkernel CMA pages reserved if activation fails
  2026-11-04 14:56 [PATCH] crash: keep crashkernel CMA pages reserved if activation fails Usama Arif
@ 2026-11-04 19:16 ` Bradley Morgan
  2026-11-04 21:52   ` [PATCH] crash: keep crashkernel C MA " Usama Arif
  2026-11-06 11:21 ` [PATCH] crash: keep crashkernel CMA " Mikhail Zaslonko
  2026-11-06 15:34 ` Breno Leitao
  2 siblings, 1 reply; 8+ messages in thread
From: Bradley Morgan @ 2026-11-04 19:16 UTC (permalink / raw)
  To: usama.arif
  Cc: akpm, baoquan.he, david, hannes, hbathini, jbohac, kas,
	kernel-team, kexec, leitao, linux-kernel, linux-mm,
	pasha.tatashin, pratyush, riel, rppt, ruirui.yang, shakeel.butt

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?

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] crash: keep crashkernel C MA pages reserved if activation fails
  2026-11-04 19:16 ` Bradley Morgan
@ 2026-11-04 21:52   ` Usama Arif
  2026-11-04 23:42     ` Bradley Morgan
  0 siblings, 1 reply; 8+ messages in thread
From: Usama Arif @ 2026-11-04 21:52 UTC (permalink / raw)
  To: Bradley Morgan
  Cc: Usama Arif, akpm, baoquan.he, david, hannes, hbathini, jbohac,
	kas, kernel-team, kexec, leitao, linux-kernel, linux-mm,
	pasha.tatashin, pratyush, riel, rppt, ruirui.yang, shakeel.butt

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] crash: keep crashkernel C MA pages reserved if activation fails
  2026-11-04 21:52   ` [PATCH] crash: keep crashkernel C MA " Usama Arif
@ 2026-11-04 23:42     ` Bradley Morgan
  0 siblings, 0 replies; 8+ messages in thread
From: Bradley Morgan @ 2026-11-04 23:42 UTC (permalink / raw)
  To: Usama Arif
  Cc: akpm, baoquan.he, david, hannes, hbathini, jbohac, kas,
	kernel-team, kexec, leitao, linux-kernel, linux-mm,
	pasha.tatashin, pratyush, riel, rppt, ruirui.yang, shakeel.butt

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!

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] crash: keep crashkernel CMA pages reserved if activation fails
  2026-11-04 14:56 [PATCH] crash: keep crashkernel CMA pages reserved if activation fails Usama Arif
  2026-11-04 19:16 ` Bradley Morgan
@ 2026-11-06 11:21 ` Mikhail Zaslonko
  2026-11-06 14:05   ` Usama Arif
  2026-11-06 15:34 ` Breno Leitao
  2 siblings, 1 reply; 8+ messages in thread
From: Mikhail Zaslonko @ 2026-11-06 11:21 UTC (permalink / raw)
  To: Usama Arif, Andrew Morton, baoquan.he, rppt, pasha.tatashin,
	pratyush, ruirui.yang, jbohac, david, hbathini, leitao, kexec,
	linux-mm, linux-kernel, kas, hannes, riel, shakeel.butt,
	kernel-team
  Cc: Vasily Gorbik, Heiko Carstens, Alexander Gordeev, linux-s390,
	Bradley Morgan



On 04-Nov-26 15:56, Usama Arif 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>
> ---
s390 hits this without movablecore= (adding the s390 maintainers and
linux-s390) since ZONE_DMA ends at 2G here.
CMA tries to reserve areas above 4G first, but falls back to lower
memory when it doesn't fit, so a cma area can end up across the 2G boundary.
I ran into this while adding crashkernel=,cma support for s390, which I
will post soon, and came up with the same fix.

About dropping the range instead, as you offered for v2: I'd keep this
version. With the range dropped, the kdump kernel gets less memory than
configured, and that only shows at crash time. With this patch, the
the first kernel 'loses' the memory as with a regular crashkernel= reservation
of the same size.

There is a second problem in the same loop: all areas are named
"crashkernel", which breaks the CMA sysfs and debugfs entries when
there are several. I've sent a separate fix for that:

https://lore.kernel.org/r/20261106104309.3669583-1-zaslonko@linux.ibm.com

Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Tested-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] crash: keep crashkernel CMA pages reserved if activation fails
  2026-11-06 11:21 ` [PATCH] crash: keep crashkernel CMA " Mikhail Zaslonko
@ 2026-11-06 14:05   ` Usama Arif
  2026-11-06 14:16     ` Bradley Morgan
  0 siblings, 1 reply; 8+ messages in thread
From: Usama Arif @ 2026-11-06 14:05 UTC (permalink / raw)
  To: Mikhail Zaslonko
  Cc: Usama Arif, Andrew Morton, baoquan.he, rppt, pasha.tatashin,
	pratyush, ruirui.yang, jbohac, david, hbathini, leitao, kexec,
	linux-mm, linux-kernel, kas, hannes, riel, shakeel.butt,
	kernel-team, Vasily Gorbik, Heiko Carstens, Alexander Gordeev,
	linux-s390, Bradley Morgan

On Fri, 6 Nov 2026 12:21:12 +0100 Mikhail Zaslonko <zaslonko@linux.ibm.com> wrote:

> 
> 
> On 04-Nov-26 15:56, Usama Arif 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>
> > ---
> s390 hits this without movablecore= (adding the s390 maintainers and
> linux-s390) since ZONE_DMA ends at 2G here.
> CMA tries to reserve areas above 4G first, but falls back to lower
> memory when it doesn't fit, so a cma area can end up across the 2G boundary.
> I ran into this while adding crashkernel=,cma support for s390, which I
> will post soon, and came up with the same fix.
> 
> About dropping the range instead, as you offered for v2: I'd keep this
> version. With the range dropped, the kdump kernel gets less memory than
> configured, and that only shows at crash time. With this patch, the
> the first kernel 'loses' the memory as with a regular crashkernel= reservation
> of the same size.

Yes, I do agree with this. Losing memory in first kernel is preferrable
and it will then force someone to fix whatever is broken rather than
finding out when their kernel crashes.

> 
> There is a second problem in the same loop: all areas are named
> "crashkernel", which breaks the CMA sysfs and debugfs entries when
> there are several. I've sent a separate fix for that:
> 
> https://lore.kernel.org/r/20261106104309.3669583-1-zaslonko@linux.ibm.com
> 

Thanks! I reviewed this now.

> Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
> Tested-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
> 

Thanks for testing and reviewing!

Usama

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] crash: keep crashkernel CMA pages reserved if activation fails
  2026-11-06 14:05   ` Usama Arif
@ 2026-11-06 14:16     ` Bradley Morgan
  0 siblings, 0 replies; 8+ messages in thread
From: Bradley Morgan @ 2026-11-06 14:16 UTC (permalink / raw)
  To: Usama Arif, Mikhail Zaslonko
  Cc: Andrew Morton, baoquan.he, rppt, pasha.tatashin, pratyush,
	ruirui.yang, jbohac, david, hbathini, leitao, kexec, linux-mm,
	linux-kernel, kas, hannes, riel, shakeel.butt, kernel-team,
	Vasily Gorbik, Heiko Carstens, Alexander Gordeev, linux-s390

On 6 November 2026 14:05:54 GMT, Usama Arif <usama.arif@linux.dev> wrote:
>On Fri, 6 Nov 2026 12:21:12 +0100 Mikhail Zaslonko
><zaslonko@linux.ibm.com> wrote:
>
>> 
>> 
>> On 04-Nov-26 15:56, Usama Arif 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>
>> > ---
>> s390 hits this without movablecore= (adding the s390 maintainers and
>> linux-s390) since ZONE_DMA ends at 2G here.
>> CMA tries to reserve areas above 4G first, but falls back to lower
>> memory when it doesn't fit, so a cma area can end up across the 2G
>boundary.
>> I ran into this while adding crashkernel=,cma support for s390, which I
>> will post soon, and came up with the same fix.
>> 
>> About dropping the range instead, as you offered for v2: I'd keep this
>> version. With the range dropped, the kdump kernel gets less memory than
>> configured, and that only shows at crash time. With this patch, the
>> the first kernel 'loses' the memory as with a regular crashkernel=
>reservation
>> of the same size.
>
>Yes, I do agree with this. Losing memory in first kernel is preferrable
>and it will then force someone to fix whatever is broken rather than
>finding out when their kernel crashes.
>
>> 
>> There is a second problem in the same loop: all areas are named
>> "crashkernel", which breaks the CMA sysfs and debugfs entries when
>> there are several. I've sent a separate fix for that:
>> 
>>
>https://lore.kernel.org/r/20261106104309.3669583-1-zaslonko@linux.ibm.com
>> 
>
>Thanks! I reviewed this now.
>
>> Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
>> Tested-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>

Well, now that that predicament arises, I see that this patch is a "hidden
gem" sort of thing

Reviewed-by: Bradley Morgan <brads@mainlining.org>

(Thanks for telling me about how you accounted for that bitmap_zalloc()
failure)

>> 
>
>Thanks for testing and reviewing!
>
>Usama

--- Thanks!

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] crash: keep crashkernel CMA pages reserved if activation fails
  2026-11-04 14:56 [PATCH] crash: keep crashkernel CMA pages reserved if activation fails Usama Arif
  2026-11-04 19:16 ` Bradley Morgan
  2026-11-06 11:21 ` [PATCH] crash: keep crashkernel CMA " Mikhail Zaslonko
@ 2026-11-06 15:34 ` Breno Leitao
  2 siblings, 0 replies; 8+ messages in thread
From: Breno Leitao @ 2026-11-06 15:34 UTC (permalink / raw)
  To: Usama Arif
  Cc: Andrew Morton, baoquan.he, rppt, pasha.tatashin, pratyush,
	ruirui.yang, jbohac, david, hbathini, kexec, linux-mm,
	linux-kernel, kas, hannes, riel, shakeel.butt, kernel-team

On Wed, Nov 04, 2026 at 06:56:00AM -0800, Usama Arif 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>

Tested-by: Breno Leitao <leitao@debian.org>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-11-06 15:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-04 14:56 [PATCH] crash: keep crashkernel CMA pages reserved if activation fails 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
2026-11-06 11:21 ` [PATCH] crash: keep crashkernel CMA " Mikhail Zaslonko
2026-11-06 14:05   ` Usama Arif
2026-11-06 14:16     ` Bradley Morgan
2026-11-06 15:34 ` Breno Leitao

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®