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: 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 12:23:26 -0400	[thread overview]
Message-ID: <20130529162325.GD22146@redhat.com> (raw)
In-Reply-To: <20130529135144.7f95c4c0@holzheu>

On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
> 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).

Ok. Got it. So s390 can fix it in kernel without creating any backward
compatibility issues (given the fact that nobody sees to be using
kexec-tools to build headers). 

So please go ahead and fix it and that should solve your mmap() issue
too. Also please fix kexec-tools and that change will not be backward
compatible. 

Thanks
Vivek

WARNING: multiple messages have this Message-ID (diff)
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>,
	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 12:23:26 -0400	[thread overview]
Message-ID: <20130529162325.GD22146@redhat.com> (raw)
In-Reply-To: <20130529135144.7f95c4c0@holzheu>

On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
> 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).

Ok. Got it. So s390 can fix it in kernel without creating any backward
compatibility issues (given the fact that nobody sees to be using
kexec-tools to build headers). 

So please go ahead and fix it and that should solve your mmap() issue
too. Also please fix kexec-tools and that change will not be backward
compatible. 

Thanks
Vivek

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

  reply	other threads:[~2013-05-29 16:24 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
2013-05-29 11:51                     ` Michael Holzheu
2013-05-29 16:23                     ` Vivek Goyal [this message]
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=20130529162325.GD22146@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.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 \
    --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.