All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Bernhard Walle <bwalle@suse.de>, Chandru <chandru@in.ibm.com>,
	kexec@lists.infradead.org,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	mohan@in.ibm.com, muvarov@gmail.com
Subject: Re: [patch] Possible fix for kexec-tools dynamic range allocation
Date: Wed, 21 Jan 2009 08:30:01 +1100	[thread overview]
Message-ID: <20090120212959.GA3564@verge.net.au> (raw)
In-Reply-To: <1231308086.27416.14.camel@localhost>

On Wed, Jan 07, 2009 at 05:01:26PM +1100, Michael Ellerman wrote:
> Hi all,
> 
> The patch to dynamically allocate memory regions for ppc64 kexec-tools,
> ie. "ppc64: kexec memory ranges dynamic allocation" (d182ce5), has never
> worked AFAICT.
> 
> Chandru reported it as broken when it was posted:
> http://lists.infradead.org/pipermail/kexec/2008-October/002751.html
> 
> Still, it's in now, and I'm trying to work out what's going wrong.
> 
> The symptom is as reported by Chandru, we end up not being able to
> allocate any memory (in locate_hole()). This is caused by the list of
> memory_ranges being empty.
> 
> The memory_ranges are empty because they have been realloc'ed (by the
> dynamic alloc code), and the generic code is still looking at the old
> version.
> 
> What I'm not clear on is why the ppc64 code is even calling
> setup_memory_ranges() a second time (in elf_ppc64_load()). It's already
> been called by get_memory_ranges() from my_load(). Or is there another
> route into elf_ppc64_load() that I'm not seeing?
> 
> And in fact if I just remove that call, then everything is peachy.
> 
> The following patch makes it work for me at least.

Hi Michael,

I must confess that I don't have a complete understanding of this problem.
Does Bernhard's recent patch (sorry that I applied it even though
it came in after your patch) help this problem?

commit 95c74405638c786bc76fbca5e4e8427dfe26e907
Author: Bernhard Walle <bwalle@suse.de>
Date:   Fri Jan 16 19:11:34 2009 +0100
Subject: Fix memory corruption when using realloc_memory_ranges()

> >From 40958d8f957876ca612b666f40bebf28ea335314 Mon Sep 17 00:00:00 2001
> From: Michael Ellerman <michael@ellerman.id.au>
> Date: Wed, 7 Jan 2009 16:57:05 +1100
> Subject: [PATCH] Don't call setup_memory_ranges() again
> 
> There's no need to call setup_memory_ranges() again. Furthermore it can
> lead to the memory_ranges being realloc'ed, which results in the generic
> code (locate_hole() etc.) using the free'd memory_ranges.
> 
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>  kexec/arch/ppc64/kexec-elf-ppc64.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c b/kexec/arch/ppc64/kexec-elf-ppc64.c
> index 21533cb..1e2d5a3 100644
> --- a/kexec/arch/ppc64/kexec-elf-ppc64.c
> +++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
> @@ -151,8 +151,6 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
>  	if (ramdisk && reuse_initrd)
>  		die("Can't specify --ramdisk or --initrd with --reuseinitrd\n");
>  
> -	setup_memory_ranges(info->kexec_flags);
> -
>  	/* Need to append some command line parameters internally in case of
>  	 * taking crash dumps.
>  	 */
> -- 
> 1.5.3.7.1.g4e596e
> 
> 

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@verge.net.au>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Bernhard Walle <bwalle@suse.de>,
	kexec@lists.infradead.org,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	muvarov@gmail.com
Subject: Re: [patch] Possible fix for kexec-tools dynamic range allocation
Date: Wed, 21 Jan 2009 08:30:01 +1100	[thread overview]
Message-ID: <20090120212959.GA3564@verge.net.au> (raw)
In-Reply-To: <1231308086.27416.14.camel@localhost>

On Wed, Jan 07, 2009 at 05:01:26PM +1100, Michael Ellerman wrote:
> Hi all,
> 
> The patch to dynamically allocate memory regions for ppc64 kexec-tools,
> ie. "ppc64: kexec memory ranges dynamic allocation" (d182ce5), has never
> worked AFAICT.
> 
> Chandru reported it as broken when it was posted:
> http://lists.infradead.org/pipermail/kexec/2008-October/002751.html
> 
> Still, it's in now, and I'm trying to work out what's going wrong.
> 
> The symptom is as reported by Chandru, we end up not being able to
> allocate any memory (in locate_hole()). This is caused by the list of
> memory_ranges being empty.
> 
> The memory_ranges are empty because they have been realloc'ed (by the
> dynamic alloc code), and the generic code is still looking at the old
> version.
> 
> What I'm not clear on is why the ppc64 code is even calling
> setup_memory_ranges() a second time (in elf_ppc64_load()). It's already
> been called by get_memory_ranges() from my_load(). Or is there another
> route into elf_ppc64_load() that I'm not seeing?
> 
> And in fact if I just remove that call, then everything is peachy.
> 
> The following patch makes it work for me at least.

Hi Michael,

I must confess that I don't have a complete understanding of this problem.
Does Bernhard's recent patch (sorry that I applied it even though
it came in after your patch) help this problem?

commit 95c74405638c786bc76fbca5e4e8427dfe26e907
Author: Bernhard Walle <bwalle@suse.de>
Date:   Fri Jan 16 19:11:34 2009 +0100
Subject: Fix memory corruption when using realloc_memory_ranges()

> >From 40958d8f957876ca612b666f40bebf28ea335314 Mon Sep 17 00:00:00 2001
> From: Michael Ellerman <michael@ellerman.id.au>
> Date: Wed, 7 Jan 2009 16:57:05 +1100
> Subject: [PATCH] Don't call setup_memory_ranges() again
> 
> There's no need to call setup_memory_ranges() again. Furthermore it can
> lead to the memory_ranges being realloc'ed, which results in the generic
> code (locate_hole() etc.) using the free'd memory_ranges.
> 
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>  kexec/arch/ppc64/kexec-elf-ppc64.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c b/kexec/arch/ppc64/kexec-elf-ppc64.c
> index 21533cb..1e2d5a3 100644
> --- a/kexec/arch/ppc64/kexec-elf-ppc64.c
> +++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
> @@ -151,8 +151,6 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
>  	if (ramdisk && reuse_initrd)
>  		die("Can't specify --ramdisk or --initrd with --reuseinitrd\n");
>  
> -	setup_memory_ranges(info->kexec_flags);
> -
>  	/* Need to append some command line parameters internally in case of
>  	 * taking crash dumps.
>  	 */
> -- 
> 1.5.3.7.1.g4e596e
> 
> 

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

  reply	other threads:[~2009-01-20 22:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-07  6:01 [patch] Possible fix for kexec-tools dynamic range allocation Michael Ellerman
2009-01-07  6:01 ` Michael Ellerman
2009-01-20 21:30 ` Simon Horman [this message]
2009-01-20 21:30   ` Simon Horman
2009-01-21  1:06   ` Michael Ellerman
2009-01-21  1:06     ` Michael Ellerman
2009-01-23 11:31   ` Chandru
2009-01-25 23:46     ` Simon Horman

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=20090120212959.GA3564@verge.net.au \
    --to=horms@verge.net.au \
    --cc=bwalle@suse.de \
    --cc=chandru@in.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=mohan@in.ibm.com \
    --cc=muvarov@gmail.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.