Messages in this thread | | | Date | Fri, 07 Feb 2014 08:04:13 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [GIT PULL] x86/kaslr for v3.14 |
| |
On 02/07/2014 06:49 AM, Vivek Goyal wrote: > > Hi Kees, > > Dave Young is testing kdump with kaslr enabled. He is facing some issues. > > One issue he mentioned is that when second kernel boots, it might be > placed in an area which is outside the reserved area for second kernel. > > We reserve a certain memory for second kernel. And modify memory map of > second kernel using memmap=exactmap parameter. Looks like kernel placement > is happening before memmap=exactmap takes effect. And that seems to be > the reason that second kernel can be placed outside the reserved memory. > > IOW, memmap=exactmap and kaslr don't work together. Is it possible to > first let memmap=exactmap take affect and then kaslr does its job. Or it > is too late by the time memmap=exactmap is parsed. > > As a workaround, Dave is currently using "nokaslr" command line parameter > for second kernel. He is still facing issues where makedumpfile segment > faults. He is looking into it further. > > I thought I will atleast bring up with issue of memmap=exactmap and kaslr > being incompatible. >
Yes, because memmap=exactmap gets parsed too late; kaslr assumes that the e820 information passed to it is actually correct.
Yet another cause of breakage caused by the decision on the part of kdump to rely on command-line options.
-hpa
| |