Re: [RFC][PATCH] Replace a function call chain of kmsg_dump(KMSG_DUMP_KEXEC) with static function calls

[ebiederm@xmission.com (Eric W. Biederman)]

Seiji Aguchi <seiji.aguchi@hds.com> writes:

> Hi,
>
> [Background]
>  - Requirement in enterprise area
>  From our support service experience, we always need to detect root causes of OS panic.
>  Because customers in enterprise area never forgive us if kdump fails and  we can't detect
>  root causes of panic due to lack of materials for investigation.
>
>  That is why I would like to add kmsg_dump() in kdump path.

You are whittling this down to something that has a chance of being
useful, but the code still has a ways to go.

It is good that you have managed to run tests that on one hardware
platform the firmware is reliable and that this does not reduce the odds
of kexec.  Your starting assertion however is that you can not do this
in the kernel started by kexec on panic because kexec on panic is
unreliable.  You don't have test cases that show your code working
when the kexec on panic kernel does not.

Calling out to EFI continues not to inspire my confidence that this
code will work on a wide variety of hardware platforms.

What is going on with EFI support?  We are still making efi calls in
virtual mode, and we don't have the one unified identity mapped physical
page table that hpa and I think others were working a while back.  Even
if because of bugs we need to transition EFI to virtual mode we can
still set physical to virtual so we don't have to deal with the nonsense.

Can we please make our EFI support ask the minimal from EFI before
adding lots more to it?

Am I wrong in thinking that the core motivation behind this patch is
that our EFI support sucks and thus kdump on EFI does not work on some
platforms?

Eric