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:	Fri, 24 May 2013 17:06:26 +0200
From:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	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
Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390

Hello Vivek,

On Fri, 24 May 2013 10:36:44 -0400
Vivek Goyal <vgoyal@...hat.com> wrote:

[snip]

> Sorry, I don't understand the problem. If we swapped low memory and
> crash reserved memory, that should have been taken care by prepared
> ELF headers so that we map the right pfns. In x86 we swap 640K of low
> memory with 640K of memory in reserved and we take care of this by
> preparing elf headers accordingly.
> 
> So why s390 can't do the same thing?

I am not sure if I understand this. Currently we create the ELF
header in a way that we have virtual=real. In the copy_oldmem_page() we
do the swap so that for the /proc/vmcore code it looks like contiguous
non-swapped memory.

One reason why I thought this was necessary was that /dev/oldmem
also uses the function and it should provide linear memory access like
it is on the live system with /dev/mem.

Is that implementation incorrect?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ