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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux