James, On 01/21/2016 11:17 PM, James Morse wrote: > 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. Good point! > Is it worth preventing this corner case by getting kexec-tools to > prevent linux with a different endianness being loaded as a kdump kernel? It may be, but I think that people should always check whether or not kdump will work in their environment before puting the system in practical use. (I know the check costs almost nothing though.) Thanks, -Takahiro AKASHI > > Thanks, > > James > >
