From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: Baoquan he <bhe@redhat.com>, Jiri Bohac <jbohac@suse.cz>,
Hari Bathini <hbathini@linux.ibm.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Mahesh Salgaonkar <mahesh@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Shivang Upadhyay <shivangu@linux.ibm.com>,
kexec@lists.infradead.org
Subject: Re: [PATCH v5] powerpc/kdump: Add support for crashkernel CMA reservation
Date: Tue, 04 Nov 2025 16:21:41 +0530 [thread overview]
Message-ID: <87tsza3waq.ritesh.list@gmail.com> (raw)
In-Reply-To: <722d72b5-cebf-48f2-8ad5-558ccd3c30f4@linux.ibm.com>
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> On 04/11/25 15:48, Ritesh Harjani (IBM) wrote:
>> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>>
>>
>>> I would like to keep kdump_cma_reserve() as is it because of two reasons:
>>>
>>> - It keeps setup_arch() free from kdump #ifdefs
>> Not really.
>>
>> Instead of kdump_cma_reserve(crashk_cma_size), one could call
>>
>> reserve_crashkernel_cma(crashk_cma_size) directly in setup_arch().
>
>
> reserve_crashkernel_cma() is not available unless the kernel is built
> with CONFIG_CRASH_RESERVE.
> So, wouldn’t calling reserve_crashkernel_cma() directly from
> setup_arch() lead to a build failure? Or
> am I missing something?
>
OOps.. I was assuming the #else CRASHKERNEL_CMA definition should get
called, but all of that logic itself is protected in
CONFIG_CRASH_RESERVE :(
Right to avoid #ifdef or IS_ENABLED in setup_arch..
it's better to have kdump_cma_reserve()
Thanks for pointing that out.
<snip>
obj-$(CONFIG_CRASH_RESERVE) += crash_reserve.o
kernel/crash_reserve.c
#ifdef CRASHKERNEL_CMA
int crashk_cma_cnt;
void __init reserve_crashkernel_cma(unsigned long long cma_size)
{
...
}
#else /* CRASHKERNEL_CMA */
void __init reserve_crashkernel_cma(unsigned long long cma_size)
{
if (cma_size)
pr_warn("crashkernel CMA reservation not supported\n");
}
#endif
-ritesh
>>
>>> - In case if we want to add some condition on this reservation it would
>>> straight forward.
>>>
>> Make sense.
>>
>>> So lets keep kdump_cma_reserve as is, unless you have strong opinion on
>>> not to.
>>>
>> No strong opinion, as I said it was a minor nit. Feel free to keep the
>> function kdump_cma_reserve() as is then.
>>
>> -ritesh
>>
prev parent reply other threads:[~2025-11-04 11:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 4:37 [PATCH v5] powerpc/kdump: Add support for crashkernel CMA reservation Sourabh Jain
2025-11-03 10:10 ` Ritesh Harjani
2025-11-04 5:18 ` Sourabh Jain
2025-11-04 9:34 ` Sourabh Jain
2025-11-04 10:24 ` Ritesh Harjani
2025-11-04 12:38 ` Sourabh Jain
2025-11-04 10:18 ` Ritesh Harjani
2025-11-04 10:35 ` Sourabh Jain
2025-11-04 10:51 ` Ritesh Harjani [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=87tsza3waq.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=bhe@redhat.com \
--cc=hbathini@linux.ibm.com \
--cc=jbohac@suse.cz \
--cc=kexec@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mahesh@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=shivangu@linux.ibm.com \
--cc=sourabhjain@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.