From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
Jan Willeke <willeke@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Subject: Re: [PATCH 0/4] kdump: Allow ELF header creation in new kernel
Date: Tue, 7 May 2013 12:37:01 -0400 [thread overview]
Message-ID: <20130507163701.GA14403@redhat.com> (raw)
In-Reply-To: <1367845799-29125-1-git-send-email-holzheu@linux.vnet.ibm.com>
On Mon, May 06, 2013 at 03:09:55PM +0200, Michael Holzheu wrote:
> Hello Vivek,
>
> For s390 we want to use /proc/vmcore for our SCSI stand-alone
> dump (zfcpdump). We have support where the first HSA_SIZE bytes are
> saved into a hypervisor owned memory area (HSA) before the kdump
> kernel is booted. When the kdump kernel starts, it is restricted
> to use only HSA_SIZE bytes.
>
Hi Michael,
Hatayama is changing /proc/vmcore interface to support mmap(). Can you
please rebase your changes on top of those patches.
http://thread.gmane.org/gmane.linux.kernel/1477622
Secondly, I think /proc/vmcore does not have to know whether elf
headers are in old memory or new memory. Given that s390 is taking
a deviation, so it now becomes an arch specific detail. Can't we
just create few arch specific helper functions to retrieve and free
elf headers.
- arch_get_crash_headers()
- All arch except return elfcorehdr_add except s390.
- arch_read_crash_header_data()
- All arch just call into read_from_oldmem() except s390. We
can provide a generic implementation in /proc/vmcore.c so
all other arch can use that generic implementation. Or
use symbol override trick.
- arch_free_crash_headers()
- All arch do nothing except s390 which can reclaim the memory
for elf headers prepared. Generic code has parsed/copied the
headers by now.
What do you think? Above 3 calls should solve the problem and allow
arch to handle elf headers differently. And generic implementation
still keeps common logic for processing headers.
Thanks
Vivek
next prev parent reply other threads:[~2013-05-07 16:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 13:09 [PATCH 0/4] kdump: Allow ELF header creation in new kernel Michael Holzheu
2013-05-06 13:09 ` [PATCH 1/4] kdump: Introduce ELFCORE_ADDR_NEWMEM Michael Holzheu
2013-05-06 13:09 ` [PATCH 2/4] s390/kdump: Use ELFCORE_ADDR_NEWMEM for kdump Michael Holzheu
2013-05-06 13:09 ` [PATCH 3/4] s390/kdump: Use ELFCORE_ADDR_NEWMEM for zfcpdump Michael Holzheu
2013-05-06 13:09 ` [PATCH 4/4] kdump: Merge set_vmcore_list_offsets_elf64/elf32/newmem Michael Holzheu
2013-05-07 16:37 ` Vivek Goyal [this message]
2013-05-08 15:28 ` [PATCH 0/4] kdump: Allow ELF header creation in new kernel 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=20130507163701.GA14403@redhat.com \
--to=vgoyal@redhat.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=heiko.carstens@de.ibm.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--cc=willeke@de.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox