All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: kexec@lists.infradead.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org, Jan Willeke <willeke@de.ibm.com>,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.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

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

WARNING: multiple messages have this Message-ID (diff)
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

  parent reply	other threads:[~2013-05-07 16:39 UTC|newest]

Thread overview: 14+ 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 ` Michael Holzheu
2013-05-06 13:09 ` [PATCH 1/4] kdump: Introduce ELFCORE_ADDR_NEWMEM Michael Holzheu
2013-05-06 13:09   ` 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   ` 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   ` Michael Holzheu
2013-05-06 13:09 ` [PATCH 4/4] kdump: Merge set_vmcore_list_offsets_elf64/elf32/newmem Michael Holzheu
2013-05-06 13:09   ` Michael Holzheu
2013-05-07 16:37 ` Vivek Goyal [this message]
2013-05-07 16:37   ` [PATCH 0/4] kdump: Allow ELF header creation in new kernel Vivek Goyal
2013-05-08 15:28   ` Michael Holzheu
2013-05-08 15:28     ` 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 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.