From: Anton Blanchard <anton@samba.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ian Munsie <imunsie@au1.ibm.com>,
Benjamin Herrenschmidt <benh@au1.ibm.com>,
linuxppc-dev <linuxppc-dev@ozlabs.org>,
Michael Neuling <michael.neuling@au1.ibm.com>,
"sonal.santan" <sonal.santan@xilinx.com>,
Jeremy Kerr <jk@ozlabs.org>,
Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Subject: Re: [PATCH] Fix crash due to processing "memory-controller" nodes as "memory"
Date: Wed, 22 Jul 2015 09:18:44 +1000 [thread overview]
Message-ID: <20150722091844.114ea023@kryten> (raw)
In-Reply-To: <1437447984.30722.3.camel@ellerman.id.au>
Hi,
> > Nice catch! I wonder if we should be checking for device_type
> > "memory". Ben?
>
> Yes. That's what Linux does.
Ian: I made that change, and slightly modified your commit message.
Look ok?
Anton
--
[PATCH] Fix crash due to processing "memory-controller" nodes as "memory"
If the system has a PCI device with a memory-controller device node,
kexec-lite would spew hundreds of double free warnings and eventually
segfault. This would result in a "kexec load failed" message from
petitboot.
This was due to kexec_memory_map() searching for "memory" nodes, but
actually matching any node that started with "memory", including these
"memory-controller" nodes. This patch changes the search to look for
nodes with a device_type of "memory", which should only match memory
nodes.
An example of a device tree that can trigger this bug is as follows:
{
pciex@3fffe40000000 {
...
pci@0 {
#address-cells = <0x3>;
#size-cells = <0x2>;
...
memory-controller@0 {
reg = <0x10000 0x0 0x0 0x0 0x0>;
...
};
};
};
};
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
---
kexec_memory_map.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kexec_memory_map.c b/kexec_memory_map.c
index fc1b7af..6103590 100644
--- a/kexec_memory_map.c
+++ b/kexec_memory_map.c
@@ -182,7 +182,7 @@ void kexec_memory_map(void *fdt, int reserve_initrd)
}
while (1) {
- const char *name;
+ const char *type;
int len;
const fdt64_t *reg;
@@ -190,9 +190,9 @@ void kexec_memory_map(void *fdt, int reserve_initrd)
if (nodeoffset < 0)
break;
- name = fdt_get_name(fdt, nodeoffset, NULL);
+ type = fdt_getprop(fdt, nodeoffset, "device_type", NULL);
- if (!name || strncmp(name, "memory", strlen("memory")))
+ if (!type || strcmp(type, "memory"))
continue;
reg = fdt_getprop(fdt, nodeoffset, "reg", &len);
--
2.1.0
next prev parent reply other threads:[~2015-07-21 23:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 8:20 [PATCH] Fix crash due to processing "memory-controller" nodes as "memory" Ian Munsie
2015-07-20 8:25 ` Ian Munsie
2015-07-21 2:45 ` Anton Blanchard
2015-07-21 2:54 ` Benjamin Herrenschmidt
2015-07-21 3:06 ` Michael Ellerman
2015-07-21 23:18 ` Anton Blanchard [this message]
2015-07-22 0:36 ` Ian Munsie
2015-07-22 5:15 ` Anton Blanchard
2015-07-22 0:39 ` Jeremy Kerr
2015-07-22 1:32 ` Michael Neuling
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=20150722091844.114ea023@kryten \
--to=anton@samba.org \
--cc=benh@au1.ibm.com \
--cc=imunsie@au1.ibm.com \
--cc=jk@ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael.neuling@au1.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=sam.mj@au1.ibm.com \
--cc=sonal.santan@xilinx.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.