Hi! On 15/01/16 19:18, Geoff Levand wrote: > From: AKASHI Takahiro <takahiro.akashi at linaro.org> > > On crash dump kernel, all the information about primary kernel's core > image is available in elf core header specified by "elfcorehdr=" boot > parameter. reserve_elfcorehdr() will set aside the region to avoid any > corruption by crash dump kernel. > > Crash dump kernel will access the system memory of primary kernel via > copy_oldmem_page(), which reads one page by ioremap'ing it since it does > not reside in linear mapping on crash dump kernel. > Please note that we should add "mem=X[MG]" boot parameter to limit the > memory size and avoid the following assertion at ioremap(): > if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) > return NULL; > when accessing any pages beyond the usable memories of crash dump kernel. > > We also need our own elfcorehdr_read() here since the weak definition of > elfcorehdr_read() utilizes copy_oldmem_page() and will hit the assertion > above on arm64. How does this work for a different-endian crash kernel? It looks like fs/proc/vmcore.c:parse_crash_elf64_headers() does some validation on the elf-headers that doesn't look like it will work if elfcorehdr:endian != kernel:endian. Is it worth preventing this corner case by getting kexec-tools to prevent linux with a different endianness being loaded as a kdump kernel? Thanks, James
