From: Dave Anderson <anderson@redhat.com>
To: Xiao Wang/Wang Xiao <wangx.fnst@cn.fujitsu.com>
Cc: kexec@lists.infradead.org
Subject: Re: [PATCH 2/2] makedumpfile: make the incomplete vmcore generated by ENOSPC error analyzable
Date: Thu, 18 Sep 2014 09:56:06 -0400 (EDT) [thread overview]
Message-ID: <113939398.18102616.1411048566302.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <541A8769.1070604@cn.fujitsu.com>
----- Original Message -----
> >
> > For compressed kdumps, the disk_dump_header.status field currently uses these
> > three bits:
> >
> > #define DUMP_DH_COMPRESSED_ZLIB 0x1 /* page is compressed with zlib */
> > #define DUMP_DH_COMPRESSED_LZO 0x2 /* page is compressed with lzo */
> > #define DUMP_DH_COMPRESSED_SNAPPY 0x4 /* page is compressed with snappy */
> >
> > Can you please simply add a DUMP_DH_COMPRESSED_INCOMPLETE flag?
>
> OK, I'll add this flag.
>
> >
> > With respect to ELF vmcores, the processor-specific e_flags field is unused by the
> > crash utility, and it appears that makedumpfile always sets it to zero. But
> > I'm not sure what the kernel does when /proc/vmcore is created? Could there
> > be e_flags bits set there that a direct-copy of /proc/vmcore might contain?
> > That's why I suggested a unique ELF note.
>
> Add a unique ELF note is OK, and I thought it must need to allocate some diskspace
> first to store this ELF note and its data, for if the dumpfile has been modified,
> it must write a flag in this place to indicate it's an incomplete dumpfile. But
> this may waste a bit of diskspace when the dumpfile is generated with no error.
Looking at "kexec/crashdump-elf.c" in the kexec-tools package, it should be safe
to use the e_flags field, because even if /proc/vmcore were copied unmodified
(without makedumpfile), the crash_create_elf32_headers()/crash_create_elf64_headers()
functions would always set it to 0:
/* Setup ELF Header*/
elf = (EHDR *) bufp;
bufp += sizeof(EHDR);
memcpy(elf->e_ident, ELFMAG, SELFMAG);
elf->e_ident[EI_CLASS] = elf_info->class;
elf->e_ident[EI_DATA] = elf_info->data;
elf->e_ident[EI_VERSION]= EV_CURRENT;
elf->e_ident[EI_OSABI] = ELFOSABI_NONE;
memset(elf->e_ident+EI_PAD, 0, EI_NIDENT-EI_PAD);
elf->e_type = ET_CORE;
elf->e_machine = crash_architecture(elf_info);
elf->e_version = EV_CURRENT;
elf->e_entry = 0;
elf->e_phoff = sizeof(EHDR);
elf->e_shoff = 0;
elf->e_flags = 0;
elf->e_ehsize = sizeof(EHDR);
elf->e_phentsize= sizeof(PHDR);
elf->e_phnum = 0;
elf->e_shentsize= 0;
elf->e_shnum = 0;
elf->e_shstrndx = 0;
> I thought it will confuse a user when makedumpfile automatically modified the
> dumpfile name, so I'll keep the dumpfile name unchanged and use the above two
> flags in the dumpfile to indicate that it has been modified.
OK good -- thanks!
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-09-18 13:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.12983.1410860958.22890.kexec@lists.infradead.org>
2014-09-16 13:20 ` [PATCH 2/2] makedumpfile: make the incomplete vmcore generated by ENOSPC error analyzable Dave Anderson
2014-09-17 2:41 ` Wang, Xiao/Wang Xiao
2014-09-17 13:55 ` Dave Anderson
2014-09-18 7:19 ` Wang, Xiao/Wang Xiao
2014-09-18 13:56 ` Dave Anderson [this message]
2014-09-16 9:48 Wang, Xiao/Wang Xiao
2014-09-17 6:47 ` Petr Tesarik
2014-09-18 7:26 ` Wang, Xiao/Wang Xiao
2014-09-18 11:18 ` HATAYAMA, Daisuke
2014-09-18 12:29 ` HATAYAMA, Daisuke
2014-09-19 9:16 ` Wang, Xiao/Wang Xiao
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=113939398.18102616.1411048566302.JavaMail.zimbra@redhat.com \
--to=anderson@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=wangx.fnst@cn.fujitsu.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.