Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "\"Zhou, Wenjian/周文剑\"" <zhouwj-fnst@cn.fujitsu.com>
To: kumagai-atsushi@mxc.nes.nec.co.jp
Cc: kexec@lists.infradead.org
Subject: Re: [PATCH resend v2 2/3] makedumpfile: make the incomplete dumpfile generated by ENOSPC error analyzable
Date: Thu, 9 Oct 2014 09:45:27 +0800	[thread overview]
Message-ID: <5435E8B7.5030004@cn.fujitsu.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9701D4CED9@BPXM01GP.gisp.nec.co.jp>

On 10/08/2014 01:39 PM, Atsushi Kumagai wrote:
>> Since the incomplete dumpfile generated by ENOSPC error can't be anylyzed
>> by crash utility, but sometimes this file may contain important information
>> and the panic problem won't be reproduced, then we came up with an idea to
>> modify the exist data of the incomplete dumpfile to make it analyzable by
>> crash utility. And each of those dumpfiles has a flag to indicate that it
>> has been modified. As there are two formats of these dumpfiles, different
>> methods and flags are needed to deal with each of them,
>>
>> elf:
>> Modify the value of the PT_LOAD program header to reflect the actual size
>> of the incomplete dumpfile. This method can't be used to modify the dumpfile
>> written in flattened mode. This format use the "e_flags" of "elf header"
>> to indicate that it has been modified.
>
> Is it necessary to change the PT_LOAD headers in makedumpfile ?
> It sounds too much work for makedumpfile, I think it's better to
> avoid such an irreversible and more than enough change in capturing
> phase. Are there some reasons why you don't do the same thing on the
> fly in crash ?
>
> OTOH, setting the incomplete flag is certainly makedumpfile's task
> since crash can't detect ENOSPC.
>
>
> Thanks
> Atsushi Kumagai

hello

Actually, it just change the attribute:FileSiz of the PT_LOAD header 
having incomplete segment. The attribute shows the size of the segment 
in elf file. Because of that, crash can read the file correctly. And we 
haven't found it have anything to do with the original information so 
far,the information before makedumpfile. So, modifying header won't 
change too much data and won't lose any important information.

However, though it can be done in crash, the process will be much more 
complicated. I think it's not worth to do this just for that useless data.

If you think it is really needed, I will do that later.

Thanks
Zhou Wenjian


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

  reply	other threads:[~2014-10-09  1:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24  9:35 [PATCH resend v2 1/3] makedumpfile: make get_elf64_phdr()/get_elf32_phdr() public Wang Xiao
2014-09-24  9:35 ` [PATCH resend v2 2/3] makedumpfile: make the incomplete dumpfile generated by ENOSPC error analyzable Wang Xiao
2014-10-08  5:39   ` Atsushi Kumagai
2014-10-09  1:45     ` "Zhou, Wenjian/周文剑" [this message]
2014-10-10  8:11       ` Atsushi Kumagai
2014-09-24  9:35 ` [PATCH resend v2 3/3] makedumpfile: implementation of dealing with kdump-compressed dumpfile with ENOSPC error Wang Xiao
2014-10-08  5:39   ` Atsushi Kumagai
2014-09-24  9:40 ` [PATCH resend v2 1/3] makedumpfile: make get_elf64_phdr()/get_elf32_phdr() public Wang, Xiao/Wang Xiao
2014-09-25  8:48   ` Atsushi Kumagai

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=5435E8B7.5030004@cn.fujitsu.com \
    --to=zhouwj-fnst@cn.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