All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Russell King <linux@armlinux.org.uk>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Vasily Gorbik <gor@linux.ibm.com>, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
	linux-mm@kvack.org, linux-s390@vger.kernel.org
Subject: Re: [RFC/RFT PATCH 1/5] s390: make crashk_res resource a child of "System RAM"
Date: Tue, 1 Jun 2021 15:18:36 +0200	[thread overview]
Message-ID: <20210601151836.1f3a90e0@thinkpad> (raw)
In-Reply-To: <20210531122959.23499-2-rppt@kernel.org>

On Mon, 31 May 2021 15:29:55 +0300
Mike Rapoport <rppt@kernel.org> wrote:

> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> Commit 4e042af463f8 ("s390/kexec: fix crash on resize of reserved memory")
> added a comment that says "crash kernel resource should not be part of the
> System RAM resource" but never explained why. As it looks from the code in
> the kernel and in kexec there is no actual reason for that.

Still testing, but so far everything works fine.

> 
> Keeping crashk_res inline with other resources makes code simpler and
> cleaner, and allows future consolidation of the resources setup across
> several architectures.
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>  arch/s390/kernel/setup.c | 21 +++++----------------
>  1 file changed, 5 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index 5aab59ad5688..30430e7c1b03 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -500,6 +500,9 @@ static struct resource __initdata *standard_resources[] = {
>  	&code_resource,
>  	&data_resource,
>  	&bss_resource,
> +#ifdef CONFIG_CRASH_DUMP
> +	&crashk_res,
> +#endif
>  };
>  
>  static void __init setup_resources(void)
> @@ -535,7 +538,7 @@ static void __init setup_resources(void)
>  
>  		for (j = 0; j < ARRAY_SIZE(standard_resources); j++) {
>  			std_res = standard_resources[j];
> -			if (std_res->start < res->start ||
> +			if (!std_res->end || std_res->start < res->start ||
>  			    std_res->start > res->end)
>  				continue;
>  			if (std_res->end > res->end) {

Why is this extra check for !std_res->end added here? I assume it
might be needed later, after you moved this to common code, but I
cannot see how any of the other patches in this series would require
that.

> @@ -552,20 +555,6 @@ static void __init setup_resources(void)
>  			}
>  		}
>  	}
> -#ifdef CONFIG_CRASH_DUMP
> -	/*
> -	 * Re-add removed crash kernel memory as reserved memory. This makes
> -	 * sure it will be mapped with the identity mapping and struct pages
> -	 * will be created, so it can be resized later on.
> -	 * However add it later since the crash kernel resource should not be
> -	 * part of the System RAM resource.
> -	 */
> -	if (crashk_res.end) {
> -		memblock_add_node(crashk_res.start, resource_size(&crashk_res), 0);
> -		memblock_reserve(crashk_res.start, resource_size(&crashk_res));
> -		insert_resource(&iomem_resource, &crashk_res);
> -	}
> -#endif
>  }
>  
>  static void __init setup_ident_map_size(void)
> @@ -733,7 +722,7 @@ static void __init reserve_crashkernel(void)
>  		diag10_range(PFN_DOWN(crash_base), PFN_DOWN(crash_size));
>  	crashk_res.start = crash_base;
>  	crashk_res.end = crash_base + crash_size - 1;
> -	memblock_remove(crash_base, crash_size);
> +	memblock_reserve(crash_base, crash_size);
>  	pr_info("Reserving %lluMB of memory at %lluMB "
>  		"for crashkernel (System RAM: %luMB)\n",
>  		crash_size >> 20, crash_base >> 20,

Other architectures check the return value of memblock_reserve() at
this point, and exit crashkernel reservation if it fails. IIUC, the
only reason why memblock_reserve() could fail would be the same reason
why also memblock_remove() could fail, i.e. that memblock_double_array()
would fail. And since we also do not check that at the moment, your
patch would probably not (additionally) break anything.

Still, this might be something for an add-on patch (for us). Do you
happen to know how likely it would be that memblock_remove/reserve()
could fail at this point?

WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Russell King <linux@armlinux.org.uk>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Vasily Gorbik <gor@linux.ibm.com>, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
	linux-mm@kvack.org, linux-s390@vger.kernel.org
Subject: Re: [RFC/RFT PATCH 1/5] s390: make crashk_res resource a child of "System RAM"
Date: Tue, 1 Jun 2021 15:18:36 +0200	[thread overview]
Message-ID: <20210601151836.1f3a90e0@thinkpad> (raw)
In-Reply-To: <20210531122959.23499-2-rppt@kernel.org>

On Mon, 31 May 2021 15:29:55 +0300
Mike Rapoport <rppt@kernel.org> wrote:

> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> Commit 4e042af463f8 ("s390/kexec: fix crash on resize of reserved memory")
> added a comment that says "crash kernel resource should not be part of the
> System RAM resource" but never explained why. As it looks from the code in
> the kernel and in kexec there is no actual reason for that.

Still testing, but so far everything works fine.

> 
> Keeping crashk_res inline with other resources makes code simpler and
> cleaner, and allows future consolidation of the resources setup across
> several architectures.
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>  arch/s390/kernel/setup.c | 21 +++++----------------
>  1 file changed, 5 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index 5aab59ad5688..30430e7c1b03 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -500,6 +500,9 @@ static struct resource __initdata *standard_resources[] = {
>  	&code_resource,
>  	&data_resource,
>  	&bss_resource,
> +#ifdef CONFIG_CRASH_DUMP
> +	&crashk_res,
> +#endif
>  };
>  
>  static void __init setup_resources(void)
> @@ -535,7 +538,7 @@ static void __init setup_resources(void)
>  
>  		for (j = 0; j < ARRAY_SIZE(standard_resources); j++) {
>  			std_res = standard_resources[j];
> -			if (std_res->start < res->start ||
> +			if (!std_res->end || std_res->start < res->start ||
>  			    std_res->start > res->end)
>  				continue;
>  			if (std_res->end > res->end) {

Why is this extra check for !std_res->end added here? I assume it
might be needed later, after you moved this to common code, but I
cannot see how any of the other patches in this series would require
that.

> @@ -552,20 +555,6 @@ static void __init setup_resources(void)
>  			}
>  		}
>  	}
> -#ifdef CONFIG_CRASH_DUMP
> -	/*
> -	 * Re-add removed crash kernel memory as reserved memory. This makes
> -	 * sure it will be mapped with the identity mapping and struct pages
> -	 * will be created, so it can be resized later on.
> -	 * However add it later since the crash kernel resource should not be
> -	 * part of the System RAM resource.
> -	 */
> -	if (crashk_res.end) {
> -		memblock_add_node(crashk_res.start, resource_size(&crashk_res), 0);
> -		memblock_reserve(crashk_res.start, resource_size(&crashk_res));
> -		insert_resource(&iomem_resource, &crashk_res);
> -	}
> -#endif
>  }
>  
>  static void __init setup_ident_map_size(void)
> @@ -733,7 +722,7 @@ static void __init reserve_crashkernel(void)
>  		diag10_range(PFN_DOWN(crash_base), PFN_DOWN(crash_size));
>  	crashk_res.start = crash_base;
>  	crashk_res.end = crash_base + crash_size - 1;
> -	memblock_remove(crash_base, crash_size);
> +	memblock_reserve(crash_base, crash_size);
>  	pr_info("Reserving %lluMB of memory at %lluMB "
>  		"for crashkernel (System RAM: %luMB)\n",
>  		crash_size >> 20, crash_base >> 20,

Other architectures check the return value of memblock_reserve() at
this point, and exit crashkernel reservation if it fails. IIUC, the
only reason why memblock_reserve() could fail would be the same reason
why also memblock_remove() could fail, i.e. that memblock_double_array()
would fail. And since we also do not check that at the moment, your
patch would probably not (additionally) break anything.

Still, this might be something for an add-on patch (for us). Do you
happen to know how likely it would be that memblock_remove/reserve()
could fail at this point?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-06-01 13:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-31 12:29 [RFC/RFT PATCH 0/5] consolidate "System RAM" resources setup Mike Rapoport
2021-05-31 12:29 ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 1/5] s390: make crashk_res resource a child of "System RAM" Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-06-01  8:45   ` David Hildenbrand
2021-06-01  8:45     ` David Hildenbrand
2021-06-01  9:02     ` David Hildenbrand
2021-06-01  9:02       ` David Hildenbrand
2021-06-02  6:25       ` Mike Rapoport
2021-06-02  6:25         ` Mike Rapoport
2021-06-01 13:18   ` Gerald Schaefer [this message]
2021-06-01 13:18     ` Gerald Schaefer
2021-06-02  6:54     ` Mike Rapoport
2021-06-02  6:54       ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 2/5] memblock: introduce generic memblock_setup_resources() Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-06-01 13:54   ` Russell King (Oracle)
2021-06-01 13:54     ` Russell King (Oracle)
2021-06-02  8:33     ` Mike Rapoport
2021-06-02  8:33       ` Mike Rapoport
2021-06-02 10:15       ` Russell King (Oracle)
2021-06-02 10:15         ` Russell King (Oracle)
2021-06-02 13:54         ` Mike Rapoport
2021-06-02 13:54           ` Mike Rapoport
2021-06-02 15:51           ` Russell King (Oracle)
2021-06-02 15:51             ` Russell King (Oracle)
2021-06-02 18:43             ` Mike Rapoport
2021-06-02 18:43               ` Mike Rapoport
2021-06-02 20:15               ` Russell King (Oracle)
2021-06-02 20:15                 ` Russell King (Oracle)
2021-06-03 10:32                 ` Mike Rapoport
2021-06-03 10:32                   ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 3/5] arm: switch to " Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 4/5] MIPS: switch to generic memblock_setup_resources Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 5/5] arm64: switch to generic memblock_setup_resources() Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-06-01 13:44 ` [RFC/RFT PATCH 0/5] consolidate "System RAM" resources setup Russell King (Oracle)
2021-06-01 13:44   ` Russell King (Oracle)
2021-06-02  7:05   ` Mike Rapoport
2021-06-02  7:05     ` Mike Rapoport

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=20210601151836.1f3a90e0@thinkpad \
    --to=gerald.schaefer@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=will@kernel.org \
    /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.