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, 3 Nov 2006 03:20:58 +0900
From:	"Magnus Damm" <magnus.damm@...il.com>
To:	"Andi Kleen" <ak@....de>
Cc:	"Magnus Damm" <magnus@...inux.co.jp>, linux-kernel@...r.kernel.org,
	"Mel Gorman" <mel@....ul.ie>, "Vivek Goyal" <vgoyal@...ibm.com>,
	fastboot@...ts.osdl.org
Subject: Re: [PATCH] x86_64: setup saved_max_pfn correctly (kdump)

On 2 Nov 2006 18:40:16 +0100, Andi Kleen <ak@....de> wrote:
> On Thu, Nov 02, 2006 at 10:19:34PM +0900, Magnus Damm wrote:
> > x86_64: setup saved_max_pfn correctly
> >
> > 2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible
> > to read out the kernel contents from /proc/vmcore because saved_max_pfn is set
> > to zero instead of the max_pfn value before the user map is setup.
>
> Do you know what patch has broken it?

Not really. I can find out if you want, but it has to wait until the
middle of next week - I'm out of the office at the moment. If I have
to guess then I point in Mel's direction. =)

> Or did just nobody test crash dump at all since -rc* started?

I think the problem is what to test. The entire chain of crash dump
tools is in an "interesting" state right now because the code is
pretty easy to break and it is under constant development - the
relocatable kernel code and my and Simon's kexec port for xen are two
good examples. And that the code is spread out over two kernels that
may not be of the same version together with a more or less
unmaintained userspace tool does not help...

I hope that someone else than me booted a crash kernel, but it looks
like noone really tested copying a crash image on x86_64. I didn't
until now. =) It's not that surprising though - there are only a few
kexec/kdump developers out there and there are several architectures
plus focus on features. Bound to break IMO.

Thanks,

/ magnus
-
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