linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dyoung@redhat.com (Dave Young)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: kexec: fix crashkernel= handling
Date: Fri, 8 Apr 2016 10:12:01 +0800	[thread overview]
Message-ID: <20160408021201.GA4186@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <E1aoH5h-0003LZ-O9@rmk-PC.arm.linux.org.uk>

On 04/07/16 at 10:03pm, Russell King wrote:
> When the kernel crashkernel parameter is specified with just a size, we
> are supposed to allocate a region from RAM to store the crashkernel.
> However, ARM merely reserves physical address zero with no checking that
> there is even RAM there.
> 
> Fix this by lifting similar code from x86, importing it to ARM with the
> ARM specific parameters added.  In the absence of any platform specific
> information, we allocate the crashkernel region from the first 512MB of
> physical memory.
> 
> Update the kdump documentation to reflect this change.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  Documentation/kdump/kdump.txt | 13 +++----------
>  arch/arm/kernel/setup.c       | 29 +++++++++++++++++++++++++++++
>  2 files changed, 32 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index bc4bd5a44b88..88ff63d5fde3 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -263,12 +263,6 @@ been removed from the machine.
>      crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
>      range=start-[end]
>  
> -Please note, on arm, the offset is required.
> -    crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
> -    range=start-[end]
> -
> -    'start' is inclusive and 'end' is exclusive.
> -
>  For example:
>  
>      crashkernel=512M-2G:64M,2G-:128M
> @@ -307,10 +301,9 @@ Boot into System Kernel
>     on the memory consumption of the kdump system. In general this is not
>     dependent on the memory size of the production system.
>  
> -   On arm, use "crashkernel=Y at X". Note that the start address of the kernel
> -   will be aligned to 128MiB (0x08000000), so if the start address is not then
> -   any space below the alignment point may be overwritten by the dump-capture kernel,
> -   which means it is possible that the vmcore is not that precise as expected.
> +   On arm, the use of "crashkernel=Y at X" is no longer necessary; the
> +   kernel will automatically locate the crash kernel image within the
> +   first 512MB of RAM if X is not given.
>  
>  
>  Load the Dump-capture Kernel
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 139791ed473d..77b54c461c52 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
>  late_initcall(init_machine_late);
>  
>  #ifdef CONFIG_KEXEC
> +/*
> + * The crash region must be aligned to 128MB to avoid
> + * zImage relocating below the reserved region.
> + */
> +#define CRASH_ALIGN	(128 << 20)
> +#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
> +
>  static inline unsigned long long get_total_mem(void)
>  {
>  	unsigned long total;
> @@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
>  	if (ret)
>  		return;
>  
> +	if (crash_base <= 0) {
> +		unsigned long long crash_max = CRASH_ADDR_MAX;
> +		if (crash_max > (u32)~0)
> +			crash_max = (u32)~0;
> +		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> +						    crash_size, CRASH_ALIGN);
> +		if (!crash_base) {
> +			pr_err("crashkernel reservation failed - No suitable area found.\n");
> +			return;
> +		}
> +	} else {
> +		unsigned long long start;
> +
> +		start = memblock_find_in_range(crash_base,
> +					       crash_base + crash_size,
> +					       crash_size, SECTION_SIZE);
> +		if (start != crash_base) {
> +			pr_err("crashkernel reservation failed - memory is in use.\n");
> +			return;
> +		}
> +	}
> +
>  	ret = memblock_reserve(crash_base, crash_size);
>  	if (ret < 0) {
>  		pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",

Reviewed-by: Dave Young <dyoung@redhat.com>

Thanks
Dave

      reply	other threads:[~2016-04-08  2:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 10:10 [PATCH] ARM: kexec: fix crashkernel= handling Russell King
2016-03-30  1:46 ` Dave Young
2016-03-30 12:39   ` Pratyush Anand
2016-03-30 13:05     ` Russell King - ARM Linux
2016-03-30 13:27       ` Vivek Goyal
2016-04-01 13:25         ` Russell King - ARM Linux
2016-04-06  6:57           ` Dave Young
2016-04-07 21:03 ` [PATCH v2] " Russell King
2016-04-08  2:12   ` Dave Young [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=20160408021201.GA4186@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).