linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: vgoyal@redhat.com, bhe@redhat.com, mpe@ellerman.id.au,
	bauerman@linux.vnet.ibm.com, prudo@linux.vnet.ibm.com,
	kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 5/7] x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
Date: Fri, 2 Mar 2018 13:31:53 +0800	[thread overview]
Message-ID: <20180302053153.GC2952@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20180227044814.24808-6-takahiro.akashi@linaro.org>

On 02/27/18 at 01:48pm, AKASHI Takahiro wrote:
> While CRASH_MAX_RANGES (== 16) seems to be good enough, fixed-number
> array is not a good idea in general.
> 
> In this patch, size of crash_mem buffer is calculated as before and
> the buffer is now dynamically allocated. This change also allows removing
> crash_elf_data structure.
> 
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> ---
>  arch/x86/kernel/crash.c | 80 ++++++++++++++++++-------------------------------
>  1 file changed, 29 insertions(+), 51 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 913fd8021f8a..bfc37ad20d4a 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -41,32 +41,14 @@
>  /* Alignment required for elf header segment */
>  #define ELF_CORE_HEADER_ALIGN   4096
>  
> -/* This primarily represents number of split ranges due to exclusion */
> -#define CRASH_MAX_RANGES	16
> -
>  struct crash_mem_range {
>  	u64 start, end;
>  };
>  
>  struct crash_mem {
> -	unsigned int nr_ranges;
> -	struct crash_mem_range ranges[CRASH_MAX_RANGES];
> -};
> -
> -/* Misc data about ram ranges needed to prepare elf headers */
> -struct crash_elf_data {
> -	struct kimage *image;
> -	/*
> -	 * Total number of ram ranges we have after various adjustments for
> -	 * crash reserved region, etc.
> -	 */
>  	unsigned int max_nr_ranges;
> -
> -	/* Pointer to elf header */
> -	void *ehdr;
> -	/* Pointer to next phdr */
> -	void *bufp;
> -	struct crash_mem mem;
> +	unsigned int nr_ranges;
> +	struct crash_mem_range ranges[0];
>  };
>  
>  /* Used while preparing memory map entries for second kernel */
> @@ -217,26 +199,29 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> -
>  /* Gather all the required information to prepare elf headers for ram regions */
> -static void fill_up_crash_elf_data(struct crash_elf_data *ced,
> -				   struct kimage *image)
> +static struct crash_mem *fill_up_crash_elf_data(void)
>  {
>  	unsigned int nr_ranges = 0;
> -
> -	ced->image = image;
> +	struct crash_mem *cmem;
>  
>  	walk_system_ram_res(0, -1, &nr_ranges,
>  				get_nr_ram_ranges_callback);

I know it is probably not possible fail here, but for safe we can check
if nr_ranges == 0

>  
> -	ced->max_nr_ranges = nr_ranges;
> +	/*
> +	 * Exclusion of crash region and/or crashk_low_res may cause
> +	 * another range split. So add extra two slots here.
> +	 */
> +	nr_ranges += 2;
> +	cmem = vmalloc(sizeof(struct crash_mem) +
> +			sizeof(struct crash_mem_range) * nr_ranges);
> +	if (!cmem)
> +		return NULL;

vzalloc will be better. 

>  
> -	/* Exclusion of crash region could split memory ranges */
> -	ced->max_nr_ranges++;
> +	cmem->max_nr_ranges = nr_ranges;
> +	cmem->nr_ranges = 0;
>  
> -	/* If crashk_low_res is not 0, another range split possible */
> -	if (crashk_low_res.end)
> -		ced->max_nr_ranges++;
> +	return cmem;
>  }
>  
>  static int exclude_mem_range(struct crash_mem *mem,
> @@ -293,10 +278,8 @@ static int exclude_mem_range(struct crash_mem *mem,
>  		return 0;
>  
>  	/* Split happened */
> -	if (i == CRASH_MAX_RANGES - 1) {
> -		pr_err("Too many crash ranges after split\n");
> +	if (i == mem->max_nr_ranges - 1)
>  		return -ENOMEM;
> -	}
>  
>  	/* Location where new range should go */
>  	j = i + 1;
> @@ -314,11 +297,10 @@ static int exclude_mem_range(struct crash_mem *mem,
>  
>  /*
>   * Look for any unwanted ranges between mstart, mend and remove them. This
> - * might lead to split and split ranges are put in ced->mem.ranges[] array
> + * might lead to split and split ranges are put in cmem->ranges[] array
>   */
> -static int elf_header_exclude_ranges(struct crash_elf_data *ced)
> +static int elf_header_exclude_ranges(struct crash_mem *cmem)
>  {
> -	struct crash_mem *cmem = &ced->mem;
>  	int ret = 0;
>  
>  	/* Exclude crashkernel region */
> @@ -337,8 +319,7 @@ static int elf_header_exclude_ranges(struct crash_elf_data *ced)
>  
>  static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
>  {
> -	struct crash_elf_data *ced = arg;
> -	struct crash_mem *cmem = &ced->mem;
> +	struct crash_mem *cmem = arg;
>  
>  	cmem->ranges[cmem->nr_ranges].start = res->start;
>  	cmem->ranges[cmem->nr_ranges].end = res->end;
> @@ -347,7 +328,7 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> -static int prepare_elf64_headers(struct crash_elf_data *ced, int kernel_map,
> +static int prepare_elf64_headers(struct crash_mem *cmem, int kernel_map,
>  		void **addr, unsigned long *sz)
>  {
>  	Elf64_Ehdr *ehdr;
> @@ -356,12 +337,11 @@ static int prepare_elf64_headers(struct crash_elf_data *ced, int kernel_map,
>  	unsigned char *buf, *bufp;
>  	unsigned int cpu, i;
>  	unsigned long long notes_addr;
> -	struct crash_mem *cmem = &ced->mem;
>  	unsigned long mstart, mend;
>  
>  	/* extra phdr for vmcoreinfo elf note */
>  	nr_phdr = nr_cpus + 1;
> -	nr_phdr += ced->max_nr_ranges;
> +	nr_phdr += cmem->nr_ranges;
>  
>  	/*
>  	 * kexec-tools creates an extra PT_LOAD phdr for kernel text mapping
> @@ -455,29 +435,27 @@ static int prepare_elf64_headers(struct crash_elf_data *ced, int kernel_map,
>  static int prepare_elf_headers(struct kimage *image, void **addr,
>  					unsigned long *sz)
>  {
> -	struct crash_elf_data *ced;
> +	struct crash_mem *cmem;
>  	Elf64_Ehdr *ehdr;
>  	Elf64_Phdr *phdr;
>  	int ret, i;
>  
> -	ced = kzalloc(sizeof(*ced), GFP_KERNEL);
> -	if (!ced)
> +	cmem = fill_up_crash_elf_data();
> +	if (!cmem)
>  		return -ENOMEM;
>  
> -	fill_up_crash_elf_data(ced, image);
> -
> -	ret = walk_system_ram_res(0, -1, ced,
> +	ret = walk_system_ram_res(0, -1, cmem,
>  				prepare_elf64_ram_headers_callback);
>  	if (ret)
>  		goto out;
>  
>  	/* Exclude unwanted mem ranges */
> -	ret = elf_header_exclude_ranges(ced);
> +	ret = elf_header_exclude_ranges(cmem);
>  	if (ret)
>  		goto out;
>  
>  	/* By default prepare 64bit headers */
> -	ret =  prepare_elf64_headers(ced,
> +	ret =  prepare_elf64_headers(cmem,
>  				(int)IS_ENABLED(CONFIG_X86_64), addr, sz);
>  	if (ret)
>  		goto out;
> @@ -496,7 +474,7 @@ static int prepare_elf_headers(struct kimage *image, void **addr,
>  			break;
>  		}
>  out:
> -	kfree(ced);
> +	vfree(cmem);
>  	return ret;
>  }
>  
> -- 
> 2.16.2
> 

Thanks
Dave

  reply	other threads:[~2018-03-02  5:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27  4:48 [PATCH 0/7] kexec_file: refactoring for other architecutres AKASHI Takahiro
2018-02-27  4:48 ` [PATCH 1/7] kexec_file: make an use of purgatory optional AKASHI Takahiro
2018-03-02  5:58   ` Dave Young
2018-03-02  6:11     ` Dave Young
2018-03-02  7:26       ` AKASHI Takahiro
2018-02-27  4:48 ` [PATCH 2/7] kexec_file,x86,powerpc: factor out kexec_file_ops functions AKASHI Takahiro
2018-03-02  5:04   ` Dave Young
2018-03-02  5:24     ` AKASHI Takahiro
2018-03-02  5:53       ` Dave Young
2018-03-02  6:08         ` Dave Young
2018-03-02  7:16           ` AKASHI Takahiro
2018-03-02  7:56             ` Dave Young
2018-02-27  4:48 ` [PATCH 3/7] x86: kexec_file: purge system-ram walking from prepare_elf64_headers() AKASHI Takahiro
2018-02-27  4:48 ` [PATCH 4/7] x86: kexec_file: remove X86_64 dependency " AKASHI Takahiro
2018-03-02  5:19   ` Dave Young
2018-03-02  5:33     ` AKASHI Takahiro
2018-02-27  4:48 ` [PATCH 5/7] x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer AKASHI Takahiro
2018-03-02  5:31   ` Dave Young [this message]
2018-03-02  5:36     ` AKASHI Takahiro
2018-02-27  4:48 ` [PATCH 6/7] x86: kexec_file: clean up prepare_elf64_headers() AKASHI Takahiro
2018-03-02  5:39   ` Dave Young
2018-03-02  5:58     ` AKASHI Takahiro
2018-03-02  6:04       ` Dave Young
2018-02-27  4:48 ` [PATCH 7/7] kexec_file, x86: move re-factored code to generic side AKASHI Takahiro
2018-03-02  5:56 ` [PATCH 0/7] kexec_file: refactoring for other architecutres Dave Young
2018-03-05  2:36   ` Dave Young
2018-03-06 10:28     ` AKASHI Takahiro

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=20180302053153.GC2952@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=bhe@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=prudo@linux.vnet.ibm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=vgoyal@redhat.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 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).