Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390

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