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).
Ah, that makes sense.
* 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.
Thanks for the details!
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).
Right, but if we consider "/proc/vmcore is available", a better version
would IMHO be:
bool is_kdump_kernel(void)
{
return dump_available();
}
Because that is mostly (not completely) how is_kdump_kernel() would have
worked right now *after* we had the elfcorehdr_alloc() during the
fs_init call.
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.
Same thinking here.
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.
Makes sense, so it boils down to either
bool is_kdump_kernel(void)
{
return oldmem_data.start;
}
Which means is_kdump_kernel() can be "false" even though /proc/vmcore is
available or
bool is_kdump_kernel(void)
{
return dump_available();
}
Which means is_kdump_kernel() can never be "false" if /proc/vmcore is
available. There is the chance of is_kdump_kernel() being "true" if
"elfcorehdr_alloc()" fails with -ENODEV.
You're call :) Thanks!
--
Cheers,
David / dhildenb
