All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com,
	ebiederm@xmission.com, tglx@linutronix.de, mingo@redhat.com,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Patch v2 1/3] take the segment adding out of locate_mem_hole functions
Date: Wed, 10 Sep 2014 11:20:25 -0400	[thread overview]
Message-ID: <20140910152025.GC7898@redhat.com> (raw)
In-Reply-To: <1410262580-1561-1-git-send-email-bhe@redhat.com>

On Tue, Sep 09, 2014 at 07:36:18PM +0800, Baoquan He wrote:
> In locate_mem_hole functions, a memory hole is located and added as
> kexec_segment. But from the name of locate_mem_hole, it should only
> take responsibility of searching a available memory hole to contain
> data of a specified size.
> 
> So in this patch add a new field 'mem' into kexec_buf, then take that
> kexec segment adding code out of locate_mem_hole_top_down and
> locate_mem_hole_bottom_up. This make clear of the functionality of
> locate_mem_hole just like it declars to do. And by this
> locate_mem_hole_callback chould be used later if anyone want to locate
> a memory hole for other use.
> 
> Meanwhile Vivek suggested opening code function __kexec_add_segment(),
> that way we have to retreive ksegment pointer once and it is easy to
> read. So just do it in this patch and remove __kexec_add_segment()
> since no one use it anymore.
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>

Bao,

These 3 patches look good to me. I am assuming you have tested these
to make sure nothing is broken.

Acked-by: Vivek Goyal <vgoyal@redhat.com>

Thanks
Vivek

> ---
>  include/linux/kexec.h |  1 +
>  kernel/kexec.c        | 29 ++++++++---------------------
>  2 files changed, 9 insertions(+), 21 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 4b2a0e1..9d957b7 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -178,6 +178,7 @@ struct kexec_buf {
>  	struct kimage *image;
>  	char *buffer;
>  	unsigned long bufsz;
> +	unsigned long mem;
>  	unsigned long memsz;
>  	unsigned long buf_align;
>  	unsigned long buf_min;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 2bee072..63bc3cd 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -2016,22 +2016,6 @@ static int __init crash_save_vmcoreinfo_init(void)
>  subsys_initcall(crash_save_vmcoreinfo_init);
>  
>  #ifdef CONFIG_KEXEC_FILE
> -static int __kexec_add_segment(struct kimage *image, char *buf,
> -			       unsigned long bufsz, unsigned long mem,
> -			       unsigned long memsz)
> -{
> -	struct kexec_segment *ksegment;
> -
> -	ksegment = &image->segment[image->nr_segments];
> -	ksegment->kbuf = buf;
> -	ksegment->bufsz = bufsz;
> -	ksegment->mem = mem;
> -	ksegment->memsz = memsz;
> -	image->nr_segments++;
> -
> -	return 0;
> -}
> -
>  static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
>  				    struct kexec_buf *kbuf)
>  {
> @@ -2064,8 +2048,7 @@ static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
>  	} while (1);
>  
>  	/* If we are here, we found a suitable memory range */
> -	__kexec_add_segment(image, kbuf->buffer, kbuf->bufsz, temp_start,
> -			    kbuf->memsz);
> +	kbuf->mem = temp_start;
>  
>  	/* Success, stop navigating through remaining System RAM ranges */
>  	return 1;
> @@ -2099,8 +2082,7 @@ static int locate_mem_hole_bottom_up(unsigned long start, unsigned long end,
>  	} while (1);
>  
>  	/* If we are here, we found a suitable memory range */
> -	__kexec_add_segment(image, kbuf->buffer, kbuf->bufsz, temp_start,
> -			    kbuf->memsz);
> +	kbuf->mem = temp_start;
>  
>  	/* Success, stop navigating through remaining System RAM ranges */
>  	return 1;
> @@ -2187,7 +2169,12 @@ int kexec_add_buffer(struct kimage *image, char *buffer, unsigned long bufsz,
>  	}
>  
>  	/* Found a suitable memory range */
> -	ksegment = &image->segment[image->nr_segments - 1];
> +	ksegment = &image->segment[image->nr_segments];
> +	ksegment->kbuf = kbuf->buffer;
> +	ksegment->bufsz = kbuf->bufsz;
> +	ksegment->mem = kbuf->mem;
> +	ksegment->memsz = kbuf->memsz;
> +	image->nr_segments++;
>  	*load_addr = ksegment->mem;
>  	return 0;
>  }
> -- 
> 1.8.5.3

      parent reply	other threads:[~2014-09-10 15:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 11:36 [Patch v2 1/3] take the segment adding out of locate_mem_hole functions Baoquan He
2014-09-09 11:36 ` [Patch v2 2/3] check if crashk_res_low exists when exclude it from crash mem ranges Baoquan He
2014-09-09 11:36 ` [Patch v2 3/3] kexec: remove the unused function parameter Baoquan He
2014-09-10  8:44 ` [Patch v2 1/3] take the segment adding out of locate_mem_hole functions Baoquan He
2014-09-10 15:20 ` Vivek Goyal [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=20140910152025.GC7898@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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.