From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: kexec@lists.infradead.org, kumagai-atsushi@mxc.nes.nec.co.jp
Subject: Re: [PATCH 2/2] makedumpfile: Use max_pfn from mem_map array
Date: Wed, 26 Mar 2014 18:54:26 +0100 [thread overview]
Message-ID: <20140326185426.5e2e5fc4@holzheu> (raw)
In-Reply-To: <20140326.105507.429853525.d.hatayama@jp.fujitsu.com>
On Wed, 26 Mar 2014 10:55:07 +0100 (a/T)
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> Subject: [PATCH 2/2] makedumpfile: Use max_pfn from mem_map array
> Date: Tue, 25 Mar 2014 17:14:20 +0100
[snip]
> > With this patch makedumpfile gets the maximum page frame number from
> > the mem_map array and adjusts info->max_mapnr if this value is smaller
> > than the value calculated from the ELF header.
> >
> > Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> > ---
> > makedumpfile.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > --- a/makedumpfile.c
> > +++ b/makedumpfile.c
> > @@ -2829,7 +2829,8 @@ get_mem_map_without_mm(void)
> > int
> > get_mem_map(void)
> > {
> > - int ret;
> > + unsigned long max_pfn = 0;
> > + int ret, i;
>
> Please define max_pfn as unsigned long long.
Ok done.
>
> And for i,
>
> >
> > switch (get_mem_type()) {
> > case SPARSEMEM:
> > @@ -2861,6 +2862,17 @@ get_mem_map(void)
> > ret = FALSE;
> > break;
> > }
> > + /*
> > + * Adjust "max_mapnr" for the case that Linux uses less memory
> > + * than is dumped. For example when "mem=" has been used for the
> > + * dumped system.
> > + */
> > + for (i = 0; i < info->num_mem_map; i++) {
>
> info->num_mem_map is defined as unsigned int. I guess some warning
> about comparison with different signedness occurs.
Ah ok...
With the default CFLAGS for makedumpfile-1.5.5 tarball I do not get
any warning. When I add "-W" to CFLAGS, I get lots of warnings
including the one you mentioned.
Here the fixed patch:
---
[PATCH 2/2] makedumpfile: Use max_pfn from mem_map array
There are dump mechansims like s390 stand-alond dump or KVM virsh dump
that write the physical memory of a machine and are not aware of the
dumped operating system. For those dump mechanisms it can happen
that for the Linux kernel of the dumped system the "mem=" kernel
parameter has been specified. In this case max_mapnr that makedumpfile
gets from the ELF header can be bigger than the maximum page frame number
used by the dumped Linux kernel.
With this patch makedumpfile gets the maximum page frame number from
the mem_map array and adjusts info->max_mapnr if this value is smaller
than the value calculated from the ELF header.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
makedumpfile.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2829,6 +2829,8 @@ get_mem_map_without_mm(void)
int
get_mem_map(void)
{
+ unsigned long long max_pfn = 0;
+ unsigned int i;
int ret;
switch (get_mem_type()) {
@@ -2861,6 +2863,17 @@ get_mem_map(void)
ret = FALSE;
break;
}
+ /*
+ * Adjust "max_mapnr" for the case that Linux uses less memory
+ * than is dumped. For example when "mem=" has been used for the
+ * dumped system.
+ */
+ for (i = 0; i < info->num_mem_map; i++) {
+ if (info->mem_map_data[i].mem_map == NOT_MEMMAP_ADDR)
+ continue;
+ max_pfn = MAX(max_pfn, info->mem_map_data[i].pfn_end);
+ }
+ info->max_mapnr = MIN(info->max_mapnr, max_pfn);
return ret;
}
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-03-26 17:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 16:14 [PATCH 2/2] makedumpfile: Use max_pfn from mem_map array Michael Holzheu
2014-03-26 9:55 ` HATAYAMA Daisuke
2014-03-26 17:54 ` Michael Holzheu [this message]
2014-03-27 5:19 ` Atsushi Kumagai
2014-03-27 13:54 ` Michael Holzheu
2014-03-28 11:00 ` Petr Tesarik
2014-03-28 15:54 ` Michael Holzheu
2014-03-28 16:46 ` Michael Holzheu
2014-03-28 16:53 ` Petr Tesarik
2014-03-31 9:48 ` Atsushi Kumagai
2014-03-31 10:37 ` Petr Tesarik
2014-04-01 5:06 ` Atsushi Kumagai
2014-04-01 8:11 ` Petr Tesarik
2014-04-01 9:20 ` Michael Holzheu
2014-04-03 2:38 ` Atsushi Kumagai
2014-03-31 12:59 ` Michael Holzheu
2014-03-31 10:27 ` Petr Tesarik
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=20140326185426.5e2e5fc4@holzheu \
--to=holzheu@linux.vnet.ibm.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/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