On Fri, Sep 25, 2020 at 11:05:58AM +0800, Dave Young wrote:
> Hi,
>
> On 09/24/20 at 01:16pm, [email protected] wrote:
> >
> > On 9/24/20 12:43 PM, Michael Kelley wrote:
> > > From: Eric W. Biederman <[email protected]> Sent: Thursday, September
> > > 24, 2020 9:26 AM
> > >> Michael Kelley <[email protected]> writes:
> > >>
> > >>>>> Added Hyper-V people and people who created the param, it is below
> > >>>>> commit, I also want to remove it if possible, let's see how people
> > >>>>> think, but the least way should be to disable the auto setting in
> > >>>>> both systemd
> > >>>>> and kernel:
> > >>> Hyper-V uses a notifier to inform the host system that a Linux VM has
> > >>> panic'ed. Informing the host is particularly important in a public
> > >>> cloud
> > >>> such as Azure so that the cloud software can alert the customer, and can
> > >>> track cloud-wide reliability statistics. Whether a kdump is taken is
> > >>> controlled
> > >>> entirely by the customer and how he configures the VM, and we want
> > >>> the host to be informed either way.
> > >> Why?
> > >>
> > >> Why does the host care?
> > >> Especially if the VM continues executing into a kdump kernel?
> > > The host itself doesn't care. But the host is a convenient out-of-band
> > > channel for recording that a panic has occurred and to collect basic data
> > > about the panic. This out-of-band channel is then used to notify the end
> > > customer that his VM has panic'ed. Sure, the customer should be running
> > > his own monitoring software, but customers don't always do what they
> > > should. Equally important, the out-of-band channel allows the cloud
> > > infrastructure software to notice trends, such as that the rate of Linux
> > > panics has increased, and that perhaps there is a cloud problem that
> > > should be investigated.
> >
> >
> > In many cases (especially in cloud environment) your dump device is remote
> > (e.g. iscsi) and kdump sometimes (often?) gets stuck because of
> > connectivity issues (which could be cause of the panic in the first place).
> > So it is quite desirable to inform the infrastructure that the VM is on its
> > way out without waiting for kdump to complete.
>
> That can probably be done in kdump kernel if it is really needed. Say
> informing host that panic happened and a kdump kernel is runnning.
If kdump kernel gets to that point. Sometimes (sadly) it ends up being
misconfigured and it chokes up - and hence having multiple ways to emit
the crash information before running kdump kernel is a life-saver.
>
> But I think to set crash_kexec_post_notifiers by default is still bad.
Because of the way it is run today I presume? If there was some
safe/unsafe policy that should work right? I would think that the
safe ones that work properly all the time are:
- HyperV CRASH_MSRs,
- KVM PVPANIC_[PANIC,CRASHLOAD] push button knob,
- pstore EFI variables
- Dumping in memory,
And then some that depend on firmware version (aka BIOS, and vendor) are:
- ACPI ERST,
And then the unsafe:
- s390, PowerPC (I don't actually know what they are but that
was Dave's primary motivator).
>
> >
> >
> > >
> > >> Further like I have mentioned everytime something like this has come up
> > >> a call on the kexec on panic code path should be a direct call (That can
> > >> be audited) not something hidden in a notifier call chain (which can
> > >> not).
> > >>
> >
> > We btw already have a direct call from panic() to kmsg_dump() which is
> > indirectly controlled by crash_kexec_post_notifiers, and it would also be
> > preferable to be able to call it before kdump as well.
>
> Right, that is the same thing we are talking about.
>
> Thanks
> Dave
>
