linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: kexec@lists.infradead.org
Cc: muvarov@gmail.com, linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Horms <horms@verge.net.au>
Subject: [patch] Possible fix for kexec-tools dynamic range allocation
Date: Wed, 07 Jan 2009 17:01:26 +1100	[thread overview]
Message-ID: <1231308086.27416.14.camel@localhost> (raw)

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.

cheers

>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

             reply	other threads:[~2009-01-07  6:01 UTC|newest]

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

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=1231308086.27416.14.camel@localhost \
    --to=michael@ellerman.id.au \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --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 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).