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]

Message-ID: <20130530203847.GB5968@redhat.com>
Date:	Thu, 30 May 2013 16:38:47 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Michael Holzheu <holzheu@...ux.vnet.ibm.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 Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:

[..]
> >>> 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.

Hi Michael,

Few more questions.

- What's the difference between zfcpdump and kdump. I thought zfcpdump
  just boots specific kernel from fixed drive? If yes, why can't that
  kernel prepare headers in similar way as regular kdump kernel does
  and gain from kdump kernel swap trick?

Also, we are accessing the contents of elf headers using physical
address. If that's the case, does it make a difference if data is
in old kernel's memory or new kernel's memory. We will use the physical
address and create a temporary mapping and it should not make a difference
whether same physical page is already mapped in current kernel or not.

Only restriction this places is that all ELF header needs to be
contiguous. I see that s390 code already creates elf headers using
kzalloc_panic(). So memory allocated should by physically contiguous.

So can't we just put __pa(elfcorebuf) in elfcorehdr_addr. And same
is true for p_offset fields in PT_NOTE headers and everything should
work fine?

Only problem we can face is that at some point of time kzalloc() might
not be able to contiguous memory request. We can handle that once s390
runs into those issues. You are anyway allocating memory using kzalloc().

And if this works for s390 kdump, it should work for zfcpdump too?

Thanks
Vivek
--
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/