Re: [PATCH v2 1/7] s390/kdump: implement is_kdump_kernel()

David Hildenbrand
2024-10-16T15:47:45Z

>>
>> 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