All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Zhang Yanfei <zhangyanfei.yes@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Jan Willeke <willeke@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390
Date: Wed, 29 May 2013 13:51:44 +0200	[thread overview]
Message-ID: <20130529135144.7f95c4c0@holzheu> (raw)
In-Reply-To: <20130528135500.GC7088@redhat.com>

On Tue, 28 May 2013 09:55:01 -0400
Vivek Goyal <vgoyal@redhat.com> wrote:

> On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:

[snip]

> > Besides of the newmem mechanism, for completeness, we also
> > implemented the oldmem ELF header mechansim in kexec. But this is
> > disabled by default.
> > 
> > See: "#ifdef WITH_ELF_HEADER" in kexec/arch/s390/crashdump-s390.c
> > 
> > Currently no distribution uses the oldmem mechanism.
> 
> Hi Michael,
> 
> Mechanism to read from newmem is not there yet (your patches are still
> being reviewed) and you mentioned that no distribution is building
> kexec-tools with WITH_ELF_HEADER on s390. So how things are currently
> working for kdump on s390?

Hello Vivek,

On s390, if we do not get the ELF header from the 1st kernel with
"elfcorehdr=", we build the ELF header in the 2nd kernel. This is
currently the default because WITH_ELF_HEADER is not defined for
kexec tools.

>>> START QUOTE

[PATCH v3 1/3] kdump: Introduce ELF header in new memory feature

Currently for s390 we create the ELF core header in the 2nd kernel with
a small trick. We relocate the addresses in the ELF header in a way
that for the /proc/vmcore code it seems to be in the 1st kernel (old)
memory and the read_from_oldmem() returns the correct data. This allows
the /proc/vmcore code to use the ELF header in the 2nd kernel.

>>> END QUOTE

For our current zfcpdump project (see "[PATCH 3/3]s390/kdump: Use
vmcore for zfcpdump") we could no longer use this trick. Therefore we
sent you the patches to get a clean interface for ELF header creation
in the 2nd kernel.

> > 
> > Therefore, if necessary, IMHO we can switch to the ELF header memory
> > swap mechanism for s390 in the kernel. Of course we would then also
> > have to adjust the (disabled) kexec code.
> 
> So are you saying that s390 is ready to switch to mechanism of
> creating ELF headers in first kernel by kexec-tools and new kernel
> does not have to preare ELF headers?

No, I meant that currently nobody is using the kexec tools ELF header
creation in the 1st kernel on s390. We create the ELF header in the
2nd kernel (mainly because of our cpuplugd issue).

Therefore, I think, we can safely change the ELF header creation in 2nd
kernel to use your p_offset swap trick *and* we remove the swap code in
the copy_oldmem_page() implementation (same kernel).

Best Regards,
Michael


WARNING: multiple messages have this Message-ID (diff)
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: kexec@lists.infradead.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Willeke <willeke@de.ibm.com>,
	linux-kernel@vger.kernel.org,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Zhang Yanfei <zhangyanfei.yes@gmail.com>
Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390
Date: Wed, 29 May 2013 13:51:44 +0200	[thread overview]
Message-ID: <20130529135144.7f95c4c0@holzheu> (raw)
In-Reply-To: <20130528135500.GC7088@redhat.com>

On Tue, 28 May 2013 09:55:01 -0400
Vivek Goyal <vgoyal@redhat.com> wrote:

> On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:

[snip]

> > Besides of the newmem mechanism, for completeness, we also
> > implemented the oldmem ELF header mechansim in kexec. But this is
> > disabled by default.
> > 
> > See: "#ifdef WITH_ELF_HEADER" in kexec/arch/s390/crashdump-s390.c
> > 
> > Currently no distribution uses the oldmem mechanism.
> 
> Hi Michael,
> 
> Mechanism to read from newmem is not there yet (your patches are still
> being reviewed) and you mentioned that no distribution is building
> kexec-tools with WITH_ELF_HEADER on s390. So how things are currently
> working for kdump on s390?

Hello Vivek,

On s390, if we do not get the ELF header from the 1st kernel with
"elfcorehdr=", we build the ELF header in the 2nd kernel. This is
currently the default because WITH_ELF_HEADER is not defined for
kexec tools.

>>> START QUOTE

[PATCH v3 1/3] kdump: Introduce ELF header in new memory feature

Currently for s390 we create the ELF core header in the 2nd kernel with
a small trick. We relocate the addresses in the ELF header in a way
that for the /proc/vmcore code it seems to be in the 1st kernel (old)
memory and the read_from_oldmem() returns the correct data. This allows
the /proc/vmcore code to use the ELF header in the 2nd kernel.

>>> END QUOTE

For our current zfcpdump project (see "[PATCH 3/3]s390/kdump: Use
vmcore for zfcpdump") we could no longer use this trick. Therefore we
sent you the patches to get a clean interface for ELF header creation
in the 2nd kernel.

> > 
> > Therefore, if necessary, IMHO we can switch to the ELF header memory
> > swap mechanism for s390 in the kernel. Of course we would then also
> > have to adjust the (disabled) kexec code.
> 
> So are you saying that s390 is ready to switch to mechanism of
> creating ELF headers in first kernel by kexec-tools and new kernel
> does not have to preare ELF headers?

No, I meant that currently nobody is using the kexec tools ELF header
creation in the 1st kernel on s390. We create the ELF header in the
2nd kernel (mainly because of our cpuplugd issue).

Therefore, I think, we can safely change the ELF header creation in 2nd
kernel to use your p_offset swap trick *and* we remove the swap code in
the copy_oldmem_page() implementation (same kernel).

Best Regards,
Michael


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

  reply	other threads:[~2013-05-29 11:51 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24 13:08 [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390 Michael Holzheu
2013-05-24 13:08 ` Michael Holzheu
2013-05-24 13:08 ` [PATCH 1/2] kdump/mmap: Introduce arch_oldmem_remap_pfn_range() Michael Holzheu
2013-05-24 13:08   ` Michael Holzheu
2013-05-24 13:08 ` [PATCH 2/2] s390/kdump/mmap: Implement arch_oldmem_remap_pfn_range() for s390 Michael Holzheu
2013-05-24 13:08   ` Michael Holzheu
2013-05-24 14:36 ` [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore " Vivek Goyal
2013-05-24 14:36   ` Vivek Goyal
2013-05-24 15:06   ` Michael Holzheu
2013-05-24 15:06     ` Michael Holzheu
2013-05-24 15:28     ` Vivek Goyal
2013-05-24 15:28       ` Vivek Goyal
2013-05-24 16:46       ` Michael Holzheu
2013-05-24 16:46         ` Michael Holzheu
2013-05-24 17:05         ` Vivek Goyal
2013-05-24 17:05           ` Vivek Goyal
2013-05-25 13:13           ` Michael Holzheu
2013-05-25 13:13             ` Michael Holzheu
2013-05-24 22:44       ` Eric W. Biederman
2013-05-24 22:44         ` Eric W. Biederman
2013-05-25  0:33         ` Zhang Yanfei
2013-05-25  0:33           ` Zhang Yanfei
2013-05-25  3:01           ` Eric W. Biederman
2013-05-25  3:01             ` Eric W. Biederman
2013-05-25  8:31             ` Zhang Yanfei
2013-05-25  8:31               ` Zhang Yanfei
2013-05-25 12:52               ` Michael Holzheu
2013-05-25 12:52                 ` Michael Holzheu
2013-05-28 13:55                 ` Vivek Goyal
2013-05-28 13:55                   ` Vivek Goyal
2013-05-29 11:51                   ` Michael Holzheu [this message]
2013-05-29 11:51                     ` Michael Holzheu
2013-05-29 16:23                     ` Vivek Goyal
2013-05-29 16:23                       ` Vivek Goyal
2013-05-29 17:12                       ` Michael Holzheu
2013-05-29 17:12                         ` Michael Holzheu
2013-05-30 15:00                         ` Vivek Goyal
2013-05-30 15:00                           ` Vivek Goyal
2013-05-30 20:38                     ` Vivek Goyal
2013-05-30 20:38                       ` Vivek Goyal
2013-05-31 14:21                       ` Michael Holzheu
2013-05-31 14:21                         ` Michael Holzheu
2013-05-31 16:01                         ` Vivek Goyal
2013-05-31 16:01                           ` Vivek Goyal
2013-06-03 13:27                           ` Michael Holzheu
2013-06-03 13:27                             ` Michael Holzheu
2013-06-03 15:59                             ` Vivek Goyal
2013-06-03 15:59                               ` Vivek Goyal
2013-06-03 16:48                               ` Michael Holzheu
2013-06-03 16:48                                 ` Michael Holzheu
2013-05-28 14:44                 ` Vivek Goyal
2013-05-28 14:44                   ` Vivek Goyal
2013-05-25 20:36               ` Eric W. Biederman
2013-05-25 20:36                 ` Eric W. Biederman

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=20130529135144.7f95c4c0@holzheu \
    --to=holzheu@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=vgoyal@redhat.com \
    --cc=willeke@de.ibm.com \
    --cc=zhangyanfei.yes@gmail.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.