All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
To: "holzheu@linux.vnet.ibm.com" <holzheu@linux.vnet.ibm.com>
Cc: "d.hatayama@jp.fujitsu.com" <d.hatayama@jp.fujitsu.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: RE: makedumpfile: get_max_mapnr() from ELF header problem
Date: Tue, 11 Mar 2014 06:22:41 +0000	[thread overview]
Message-ID: <0910DD04CBD6DE4193FCF86B9C00BE971F4AFE@BPXM01GP.gisp.nec.co.jp> (raw)
In-Reply-To: <20140303104408.7031a457@holzheu>

>On Mon, 3 Mar 2014 03:11:23 +0000
>Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:
>
>> Hello Michael,
>>
>> >Hello Atsushi,
>> >
>> >On s390 we have the following little problem:
>> >
>> >We use hypervisor or stand-alone dump tools to create Linux system
>> >dumps. These tools do not know the kernel parameter line and dump the
>> >full physical memory.
>> >
>> >We use makedumpfile to filter those dumps.
>> >
>> >If a Linux system has specified the "mem=" parameter, the dump tools
>> >still dump the whole phypsical memory.
>>
>> I guess this is a problem of the tools, it sounds that the tools ignore
>> the actual memory map and just make wrong ELF headers.
>> How do the tools decide the range of System RAM to create ELF headers ?
>
>The tools do a physical memory detection and that defines the range
>of memory to be dumped and also defines the memory chunks for the
>ELF header.

makedumpfile is designed for kdump, this means it relies on dependable ELF
headers. If we support such an incorrect ELF header, makedumpfile has to get
the actual memory map from vmcore (but I have no ideas how to do it now) and
re-calculate all PT_LOAD regions with it. It sounds too much work for
irregular case, I don't plan to take care of it now.

>And I think we are not the only ones that have this problem. For example,
>the KVM virsh dump probably also has that problem.

virsh dump seems to have the same issue as you said, but I suppose qemu
developers don't worry about that because they are developing an original
way to dump guest's memory in kdump-compressed format as "dump-guest-memory"
command. It seems that they know such case is out of the scope of makedumpfile.


Thanks
Atsushi Kumagai

>> At least, if the tools respect the actual memory map like /proc/vmcore, it
>> can create correct ELF headers and makedumpfile will work normally.
>
>As I said, the tools do not know the Linux memory map. They only know
>the physical available memory.
>
>Michael
>
>
>_______________________________________________
>kexec mailing list
>kexec@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec

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

  reply	other threads:[~2014-03-11  6:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 12:41 makedumpfile: get_max_mapnr() from ELF header problem Michael Holzheu
2014-03-03  3:11 ` Atsushi Kumagai
2014-03-03  9:44   ` Michael Holzheu
2014-03-11  6:22     ` Atsushi Kumagai [this message]
2014-03-11 11:35       ` Michael Holzheu
2014-03-12  4:15 ` HATAYAMA Daisuke
2014-03-12  6:01   ` Atsushi Kumagai
2014-03-12 16:18     ` Michael Holzheu
2014-03-14  8:54       ` Atsushi Kumagai
2014-03-14 14:19         ` Michael Holzheu
2014-03-19  7:14           ` Atsushi Kumagai
2014-03-19 18:29             ` Michael Holzheu
2014-03-20 10:23             ` Michael Holzheu
     [not found]             ` <20140319180903.2c6e2b72@holzheu>
2014-03-25  1:14               ` Atsushi Kumagai
2014-03-25 15:24                 ` Michael Holzheu

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=0910DD04CBD6DE4193FCF86B9C00BE971F4AFE@BPXM01GP.gisp.nec.co.jp \
    --to=kumagai-atsushi@mxc.nes.nec.co.jp \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=kexec@lists.infradead.org \
    /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.