Hi, Kees When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded high, it doesn't boot.
I reserved 128M memory at high with kernel cmdline "crashkernel=128M,high crashkernel=0,low", and for which I got: [ 0.000000] Reserving 128MB of memory at 6896MB for crashkernel (System RAM: 6013MB) Then I load kdump kernel into the reserved memory region, using a local modified kexec-tools which is passing e820 in boot_params. The e820 map of system RAM passed to 2nd kernel: E820 memmap (of RAM): 0000000000001000-000000000009e3ff (1) 00000001af000000-00000001b6f5dfff (1) 00000001b6fff400-00000001b6ffffff (1) In which, 2nd kernel is loaded at 0x1b5000000. After triggerred a system crash, 2nd kernel doesn't boot even with "nokaslr" cmdline: # echo c > /proc/sysrq-trigger [..] I'm in purgatory early console in decompress_kernel KASLR disabled... Decompressing Linux... Parsing ELF... Performing relocations... 32-bit relocation outside of kernel! -- System halted I know 32bit relocation code has recently moved to misc.c and it's a ground work for kaslr on x86_64. However it doesn't work out on a kernel high loaded case. I'm not quite familiar with this. But I'm wondering if it makes sense to skip handle_relocation() if kaslr doesn't take effects (nokaslr or kaslr failed to find suitable area). Thanks WANG Chao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
