Hi, On 09/24/20 at 01:16pm, boris.ostrov...@oracle.com wrote: > > On 9/24/20 12:43 PM, Michael Kelley wrote: > > From: Eric W. Biederman <ebied...@xmission.com> Sent: Thursday, September > > 24, 2020 9:26 AM > >> Michael Kelley <mikel...@microsoft.com> 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. But I think to set crash_kexec_post_notifiers by default is still bad. > > > > > >> 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
