All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>,
	Mahesh Salgaonkar <mahesh@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Hari Bathini <hbathini@linux.ibm.com>
Subject: Re: [PATCH v2 2/2] fadump: reserve param area if below boot_mem_top
Date: Tue, 12 Nov 2024 11:51:42 +0530	[thread overview]
Message-ID: <87zfm5m0p5.fsf@gmail.com> (raw)
In-Reply-To: <20241107055817.489795-2-sourabhjain@linux.ibm.com>

Sourabh Jain <sourabhjain@linux.ibm.com> writes:

> The param area is a memory region where the kernel places additional
> command-line arguments for fadump kernel. Currently, the param memory
> area is reserved in fadump kernel if it is above boot_mem_top. However,
> it should be reserved if it is below boot_mem_top because the fadump
> kernel already reserves memory from boot_mem_top to the end of DRAM.

did you mean s/reserves/preserves ?

>
> Currently, there is no impact from not reserving param memory if it is
> below boot_mem_top, as it is not used after the early boot phase of the
> fadump kernel. However, if this changes in the future, it could lead to
> issues in the fadump kernel.

This will only affect Hash and not radix correct? Because for radix your
param_area is somewhere within [memblock_end_of_DRAM() / 2, memblock_end_of_DRAM()]
which is anyway above boot_mem_top so it is anyway preserved as is... 

... On second thoughts since param_area during normal kernel boot anyway
comes from memblock now. And irrespective of where it falls (above or below
boot_mem_top), we anyway append the bootargs to that. So we don't really
preserve the original contents :) right? So why not just always call for
memblock_reserve() on param_area during capture kernel run?

Thoughts?

>
> Fixes: 3416c9daa6b1 ("powerpc/fadump: pass additional parameters when fadump is active")
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Acked-by: Hari Bathini <hbathini@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
>
> Changelog:
>
> Since v1: https://lore.kernel.org/all/20241104083528.99520-1-sourabhjain@linux.ibm.com/
>   - Include Fixes and Acked-by tag in the commit message
>   - No functional changes
>
> ---
>  arch/powerpc/kernel/fadump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 3a2863307863..3f3674060164 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -143,7 +143,7 @@ void __init fadump_append_bootargs(void)
>  	if (!fw_dump.dump_active || !fw_dump.param_area_supported || !fw_dump.param_area)
>  		return;
>  
> -	if (fw_dump.param_area >= fw_dump.boot_mem_top) {
> +	if (fw_dump.param_area < fw_dump.boot_mem_top) {
>  		if (memblock_reserve(fw_dump.param_area, COMMAND_LINE_SIZE)) {
>  			pr_warn("WARNING: Can't use additional parameters area!\n");
>  			fw_dump.param_area = 0;
> -- 
> 2.46.2


  reply	other threads:[~2024-11-12  7:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07  5:58 [PATCH v2 1/2] powerpc/fadump: allocate memory for additional parameters early Sourabh Jain
2024-11-07  5:58 ` [PATCH v2 2/2] fadump: reserve param area if below boot_mem_top Sourabh Jain
2024-11-12  6:21   ` Ritesh Harjani (IBM) [this message]
2024-11-12 11:04     ` Sourabh Jain
2024-11-12 11:36       ` Ritesh Harjani
2024-11-12 11:53         ` Ritesh Harjani
2024-11-12 13:03           ` Sourabh Jain
2024-11-12 13:10             ` Ritesh Harjani
2024-11-12 13:53               ` Sourabh Jain
2024-11-07 13:45 ` [PATCH v2 1/2] powerpc/fadump: allocate memory for additional parameters early Venkat
2024-11-07 13:55 ` Venkat Rao Bagalkote
2024-11-08  5:24   ` Sourabh Jain
2024-11-12  7:03 ` Ritesh Harjani (IBM)
2024-11-12 10:11   ` Sourabh Jain
2024-11-17 12:09 ` Michael Ellerman

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=87zfm5m0p5.fsf@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=hbathini@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --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.