Hi David, > My concern is that we'll now have > > bool is_kdump_kernel(void) > { > return oldmem_data.start && !is_ipl_type_dump(); > } > > Which matches 3), but if 2) is also called "kdump", then should it actually > be > > bool is_kdump_kernel(void) > { > return oldmem_data.start; > } > > ? > > When I wrote that code I was rather convinced that the variant in this patch > is the right thing to do. A short explanation about what a stand-alone kdump is. * First, it's not really a _regular_ kdump activated with kexec-tools and executed by Linux itself but a regular stand-alone dump (SCSI) from the FW's perspective (one has to use HMC or dumpconf to execute it and not with kexec-tools like for the _regular_ kdump). * One has to reserve crashkernel memory region in the old crashed kernel even if it remains unused until the dump starts. * zipl uses regular kdump kernel and initramfs to create stand-alone dumper images and to write them to a dump disk which is used for IPLIng the stand-alone dumper. * The zipl bootloader takes care of transferring the old kernel memory saved in HSA by the FW to the crashkernel memory region reserved by the old crashed kernel before it enters the dumper. The HSA memory is released by the zipl bootloader _before_ the dumper image is entered, therefore, we cannot use HSA to read old kernel memory, and instead use memory from crashkernel region, just like the regular kdump. * is_ipl_type_dump() will be true for a stand-alone kdump because we IPL the dumper like a regular stand-alone dump (e.g. zfcpdump). * Summarized, zipl bootloader prepares an environment which is expected by the regular kdump for a stand-alone kdump dumper before it is entered. In my opinion, the correct version of is_kdump_kernel() would be bool is_kdump_kernel(void) { return oldmem_data.start; } because Linux kernel doesn't differentiate between both the regular and the stand-alone kdump where it matters while performing dumper operations (e.g. reading saved old kernel memory from crashkernel memory region). Furthermore, if i'm not mistaken then the purpose of is_kdump_kernel() is to tell us whether Linux kernel runs in a kdump like environment and not whether the current mode is identical to the proper and true kdump, right ? And if stand-alone kdump swims like a duck, quacks like one, then it is one, regardless how it was started, by kexecing or IPLing from a disk. The stand-alone kdump has a very special use case which most users will never encounter. And usually, one just takes zfcpdump instead which is more robust and much smaller considering how big kdump initrd can get. stand-alone kdump dumper images cannot exceed HSA memory limit on a Z machine. Regards Alex