linux-kernel - Re: kdump fails to load and crashes [was: mmotm 2009-11-01-10-01 uploaded]

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:	Tue, 3 Nov 2009 10:24:48 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	linux-kernel@...r.kernel.org, mm-commits@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, hbabu@...ibm.com,
	kexec@...ts.infradead.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: kdump fails to load and crashes [was: mmotm 2009-11-01-10-01
	uploaded]

On Tue, Nov 03, 2009 at 04:14:25PM +0100, Jiri Slaby wrote:
> On 11/03/2009 03:44 PM, Vivek Goyal wrote:
> > On Tue, Nov 03, 2009 at 12:11:58AM +0100, Jiri Slaby wrote:
> >> On 11/01/2009 07:07 PM, akpm@...ux-foundation.org wrote:
> >>> The mm-of-the-moment snapshot 2009-11-01-10-01 has been uploaded to
> >>
> >> Hi, kdump loading crashes:
> >> BUG: unable to handle kernel paging request at ffff8800010a7000
> >> IP: [<ffffffff8101cd8b>] machine_kexec_prepare+0x16b/0x13e0
> >> PGD 1806063 PUD 180a063 PMD 10001e1
> ...
> >> ffff8800010a7000 should be OK, as crashkernel=64M@16M was passed to the
> >> kernel.
> >>
> > 
> > This is strange. As you said, ffff8800010a7000, should be a valid address
> > as you reserved memory from 16M.
> 
> Hmm, PMD has not RW bit set and we do store (see below).
> 
> > I took above -mm and for me kernel loads fine. I reserved memory 64M@32M
> > as by default kernel is loading at address 16M.
> > 
> > How does your /proc/iomem look like in first kernel?
> 
> I'm not any longer on that machine. init_pgtable() overwrites random
> memory, so possibly even host's page tables, hence the oops above, I
> suppose.
> 
> I'm currently chasing it down in the qemu virtual machine, since I
> already got a garbage into my ~/.viminfo (some overwritten page got
> flushed, I guess).
> 
> There /proc/iomem looks like:
> 00100000-12beffff : System RAM
>   01000000-04ffffff : Crash kernel
>     01000000-014680c2 : Kernel code
>     014680c3-016f39f7 : Kernel data
>     0175b000-017d97ab : Kernel bss

Hmm.., this looks fishy. Reserved memory is starting at 16MB at the same
time first kernel is loaded at 16MB. So when we try to load a crash kernel
it can try to overwrite existing kernel.

In the past if crash kernel memory area used to overlap with kernel code,
data or bss, we would not reserve the memory for "Crash Kernel" and this
entry would not appear in /proc/iomem. Not sure what has changed.

Anyway, can you just try reserving memory at some other address, say
64M@32M and see if it works.

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/