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: Thu, 30 May 2013 11:00:30 -0400	[thread overview]
Message-ID: <20130530150030.GF2864@redhat.com> (raw)
In-Reply-To: <20130529191249.19a235be@holzheu>

On Wed, May 29, 2013 at 07:12:49PM +0200, Michael Holzheu wrote:

[..]
> > > > 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. 
> 
> Ok, I will do this.
> 
> I think we should add this "swap in ELF header" patch to the "kdump:
> Allow ELF header creation in new kernel" patch series (on top of the
> mmap patch series). Because when I remove the swap code from
> copy_oldmem_page(), the old trick to access the ELF header in the first
> kernel memory will no longer work.
> 
> Is that ok for you?

I am fine with both the patches in same series.

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: Thu, 30 May 2013 11:00:30 -0400	[thread overview]
Message-ID: <20130530150030.GF2864@redhat.com> (raw)
In-Reply-To: <20130529191249.19a235be@holzheu>

On Wed, May 29, 2013 at 07:12:49PM +0200, Michael Holzheu wrote:

[..]
> > > > 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. 
> 
> Ok, I will do this.
> 
> I think we should add this "swap in ELF header" patch to the "kdump:
> Allow ELF header creation in new kernel" patch series (on top of the
> mmap patch series). Because when I remove the swap code from
> copy_oldmem_page(), the old trick to access the ELF header in the first
> kernel memory will no longer work.
> 
> Is that ok for you?

I am fine with both the patches in same series.

Thanks
Vivek

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

  reply	other threads:[~2013-05-30 15:25 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
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 [this message]
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=20130530150030.GF2864@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.