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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 May 2013 13:51:44 +0200
From:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Zhang Yanfei <zhangyanfei.yes@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
	Jan Willeke <willeke@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390

On Tue, 28 May 2013 09:55:01 -0400
Vivek Goyal <vgoyal@...hat.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/