| Message ID | 20220427224924.592546-20-gpiccoli@igalia.com |
|---|---|
| State | New |
| Headers | show |
| Series | The panic notifiers refactor | expand |
From: Guilherme G. Piccoli <gpiccoli@igalia.com> Sent: Wednesday, April 27, 2022 3:49 PM > > The goal of this new panic notifier is to allow its users to register > callbacks to run very early in the panic path. This aims hypervisor/FW > notification mechanisms as well as simple LED functions, and any other > simple and safe mechanism that should run early in the panic path; more > dangerous callbacks should execute later. > > For now, the patch is almost a no-op (although it changes a bit the > ordering in which some panic notifiers are executed). In a subsequent > patch, the panic path will be refactored, then the panic hypervisor > notifiers will effectively run very early in the panic path. > > We also defer documenting it all properly in the subsequent refactor > patch. While at it, we removed some useless header inclusions and > fixed some notifiers return too (by using the standard NOTIFY_DONE). > > Cc: Alexander Gordeev <agordeev@linux.ibm.com> > Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com> > Cc: Ard Biesheuvel <ardb@kernel.org> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Cc: Brian Norris <computersforpeace@gmail.com> > Cc: Christian Borntraeger <borntraeger@linux.ibm.com> > Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > Cc: David Gow <davidgow@google.com> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Dexuan Cui <decui@microsoft.com> > Cc: Doug Berger <opendmb@gmail.com> > Cc: Evan Green <evgreen@chromium.org> > Cc: Florian Fainelli <f.fainelli@gmail.com> > Cc: Haiyang Zhang <haiyangz@microsoft.com> > Cc: Hari Bathini <hbathini@linux.ibm.com> > Cc: Heiko Carstens <hca@linux.ibm.com> > Cc: Julius Werner <jwerner@chromium.org> > Cc: Justin Chen <justinpopo6@gmail.com> > Cc: "K. Y. Srinivasan" <kys@microsoft.com> > Cc: Lee Jones <lee.jones@linaro.org> > Cc: Markus Mayer <mmayer@broadcom.com> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Michael Kelley <mikelley@microsoft.com> > Cc: Mihai Carabas <mihai.carabas@oracle.com> > Cc: Nicholas Piggin <npiggin@gmail.com> > Cc: Paul Mackerras <paulus@samba.org> > Cc: Pavel Machek <pavel@ucw.cz> > Cc: Scott Branden <scott.branden@broadcom.com> > Cc: Sebastian Reichel <sre@kernel.org> > Cc: Shile Zhang <shile.zhang@linux.alibaba.com> > Cc: Stephen Hemminger <sthemmin@microsoft.com> > Cc: Sven Schnelle <svens@linux.ibm.com> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > Cc: Tianyu Lan <Tianyu.Lan@microsoft.com> > Cc: Vasily Gorbik <gor@linux.ibm.com> > Cc: Wang ShaoBo <bobo.shaobowang@huawei.com> > Cc: Wei Liu <wei.liu@kernel.org> > Cc: zhenwei pi <pizhenwei@bytedance.com> > Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> > --- > arch/mips/sgi-ip22/ip22-reset.c | 2 +- > arch/mips/sgi-ip32/ip32-reset.c | 3 +-- > arch/powerpc/kernel/setup-common.c | 2 +- > arch/sparc/kernel/sstate.c | 3 +-- > drivers/firmware/google/gsmi.c | 4 ++-- > drivers/hv/vmbus_drv.c | 4 ++-- > drivers/leds/trigger/ledtrig-activity.c | 4 ++-- > drivers/leds/trigger/ledtrig-heartbeat.c | 4 ++-- > drivers/misc/bcm-vk/bcm_vk_dev.c | 6 +++--- > drivers/misc/pvpanic/pvpanic.c | 4 ++-- > drivers/power/reset/ltc2952-poweroff.c | 4 ++-- > drivers/s390/char/zcore.c | 5 +++-- > drivers/soc/bcm/brcmstb/pm/pm-arm.c | 2 +- > include/linux/panic_notifier.h | 1 + > kernel/panic.c | 4 ++++ > 15 files changed, 28 insertions(+), 24 deletions(-) [ snip] > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index f37f12d48001..901b97034308 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -1614,7 +1614,7 @@ static int vmbus_bus_init(void) > hv_kmsg_dump_register(); > > register_die_notifier(&hyperv_die_report_block); > - atomic_notifier_chain_register(&panic_notifier_list, > + atomic_notifier_chain_register(&panic_hypervisor_list, > &hyperv_panic_report_block); > } > > @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void) > if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) { > kmsg_dump_unregister(&hv_kmsg_dumper); > unregister_die_notifier(&hyperv_die_report_block); > - atomic_notifier_chain_unregister(&panic_notifier_list, > + atomic_notifier_chain_unregister(&panic_hypervisor_list, > &hyperv_panic_report_block); > } > Using the hypervisor_list here produces a bit of a mismatch. In many cases this notifier will do nothing, and will defer to the kmsg_dump() mechanism to notify the hypervisor about the panic. Running the kmsg_dump() mechanism is linked to the info_list, so I'm thinking the Hyper-V panic report notifier should be on the info_list as well. That way the reporting behavior is triggered at the same point in the panic path regardless of which reporting mechanism is used.
On 29/04/2022 14:30, Michael Kelley (LINUX) wrote: > From: Guilherme G. Piccoli <gpiccoli@igalia.com> Sent: Wednesday, April 27, 2022 3:49 PM >> [...] >> >> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void) >> if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) { >> kmsg_dump_unregister(&hv_kmsg_dumper); >> unregister_die_notifier(&hyperv_die_report_block); >> - atomic_notifier_chain_unregister(&panic_notifier_list, >> + atomic_notifier_chain_unregister(&panic_hypervisor_list, >> &hyperv_panic_report_block); >> } >> > > Using the hypervisor_list here produces a bit of a mismatch. In many cases > this notifier will do nothing, and will defer to the kmsg_dump() mechanism > to notify the hypervisor about the panic. Running the kmsg_dump() > mechanism is linked to the info_list, so I'm thinking the Hyper-V panic report > notifier should be on the info_list as well. That way the reporting behavior > is triggered at the same point in the panic path regardless of which > reporting mechanism is used. > Hi Michael, thanks for your feedback! I agree that your idea could work, but...there is one downside: imagine the kmsg_dump() approach is not set in some Hyper-V guest, then we would rely in the regular notification mechanism [hv_die_panic_notify_crash()], right? But...you want then to run this notifier in the informational list, which...won't execute *by default* before kdump if no kmsg_dump() is set. So, this logic is convoluted when you mix it with the default level concept + kdump. May I suggest something? If possible, take a run with this patch set + DEBUG_NOTIFIER=y, in *both* cases (with and without the kmsg_dump() set). I did that and they run almost at the same time...I've checked the notifiers called, it's like almost nothing runs in-between. I feel the panic notification mechanism does really fit with a hypervisor list, it's a good match with the nature of the list, which aims at informing the panic notification to the hypervisor/FW. Of course we can modify it if you prefer...but please take into account the kdump case and how it complicates the logic. Let me know your considerations, in case you can experiment with the patch set as-is. Cheers, Guilherme
From: Guilherme G. Piccoli <gpiccoli@igalia.com> Sent: Friday, April 29, 2022 11:04 AM > > On 29/04/2022 14:30, Michael Kelley (LINUX) wrote: > > From: Guilherme G. Piccoli <gpiccoli@igalia.com> Sent: Wednesday, April 27, 2022 > 3:49 PM > >> [...] > >> > >> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void) > >> if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) { > >> kmsg_dump_unregister(&hv_kmsg_dumper); > >> unregister_die_notifier(&hyperv_die_report_block); > >> - atomic_notifier_chain_unregister(&panic_notifier_list, > >> + atomic_notifier_chain_unregister(&panic_hypervisor_list, > >> &hyperv_panic_report_block); > >> } > >> > > > > Using the hypervisor_list here produces a bit of a mismatch. In many cases > > this notifier will do nothing, and will defer to the kmsg_dump() mechanism > > to notify the hypervisor about the panic. Running the kmsg_dump() > > mechanism is linked to the info_list, so I'm thinking the Hyper-V panic report > > notifier should be on the info_list as well. That way the reporting behavior > > is triggered at the same point in the panic path regardless of which > > reporting mechanism is used. > > > > Hi Michael, thanks for your feedback! I agree that your idea could work, > but...there is one downside: imagine the kmsg_dump() approach is not set > in some Hyper-V guest, then we would rely in the regular notification > mechanism [hv_die_panic_notify_crash()], right? > But...you want then to run this notifier in the informational list, > which...won't execute *by default* before kdump if no kmsg_dump() is > set. So, this logic is convoluted when you mix it with the default level > concept + kdump. Yes, you are right. But to me that speaks as much to the linkage between the informational list and kmsg_dump() being the core problem. But as I described in my reply to Patch 24, I can live with the linkage as-is. FWIW, guests on newer versions of Hyper-V will always register a kmsg dumper. The flags that are tested to decide whether to register provide compatibility with older versions of Hyper-V that don’t support the 4K bytes of notification info. > > May I suggest something? If possible, take a run with this patch set + > DEBUG_NOTIFIER=y, in *both* cases (with and without the kmsg_dump() > set). I did that and they run almost at the same time...I've checked the > notifiers called, it's like almost nothing runs in-between. > > I feel the panic notification mechanism does really fit with a > hypervisor list, it's a good match with the nature of the list, which > aims at informing the panic notification to the hypervisor/FW. > Of course we can modify it if you prefer...but please take into account > the kdump case and how it complicates the logic. I agree that the runtime effect of one list vs. the other is nil. The code works and can stay as you written it. I was trying to align from a conceptual standpoint. It was a bit unexpected that one path would be on the hypervisor list, and the other path effectively on the informational list. When I see conceptual mismatches like that, I tend to want to understand why, and if there is something more fundamental that is out-of-whack. > > Let me know your considerations, in case you can experiment with the > patch set as-is. > Cheers, > > > Guilherme
On 03/05/2022 14:44, Michael Kelley (LINUX) wrote: > [...] >> >> Hi Michael, thanks for your feedback! I agree that your idea could work, >> but...there is one downside: imagine the kmsg_dump() approach is not set >> in some Hyper-V guest, then we would rely in the regular notification >> mechanism [hv_die_panic_notify_crash()], right? >> But...you want then to run this notifier in the informational list, >> which...won't execute *by default* before kdump if no kmsg_dump() is >> set. So, this logic is convoluted when you mix it with the default level >> concept + kdump. > > Yes, you are right. But to me that speaks as much to the linkage > between the informational list and kmsg_dump() being the core > problem. But as I described in my reply to Patch 24, I can live with > the linkage as-is. Thanks for the feedback Michael! > [...] >> I feel the panic notification mechanism does really fit with a >> hypervisor list, it's a good match with the nature of the list, which >> aims at informing the panic notification to the hypervisor/FW. >> Of course we can modify it if you prefer...but please take into account >> the kdump case and how it complicates the logic. > > I agree that the runtime effect of one list vs. the other is nil. The > code works and can stay as you written it. > > I was trying to align from a conceptual standpoint. It was a bit > unexpected that one path would be on the hypervisor list, and the > other path effectively on the informational list. When I see > conceptual mismatches like that, I tend to want to understand why, > and if there is something more fundamental that is out-of-whack. > Totally agree with you here, I am like that as well - try to really understand the details, this is very important specially in this patch set, since it's a refactor and affects every user of the notifiers infrastructure. Again, just to double-say it: feel free to suggest any change for the Hyper-V portion (might as well for any patch in the series, indeed) - you and the other Hyper-V maintainers own this code and I'd be glad to align with your needs, you are honor citizens in the panic notifiers area, being one the most heavy users for that =) Cheers, Guilherme
On Wed 2022-04-27 19:49:13, Guilherme G. Piccoli wrote: > The goal of this new panic notifier is to allow its users to register > callbacks to run very early in the panic path. This aims hypervisor/FW > notification mechanisms as well as simple LED functions, and any other > simple and safe mechanism that should run early in the panic path; more > dangerous callbacks should execute later. > > For now, the patch is almost a no-op (although it changes a bit the > ordering in which some panic notifiers are executed). In a subsequent > patch, the panic path will be refactored, then the panic hypervisor > notifiers will effectively run very early in the panic path. > > We also defer documenting it all properly in the subsequent refactor > patch. While at it, we removed some useless header inclusions and > fixed some notifiers return too (by using the standard NOTIFY_DONE). > --- a/arch/mips/sgi-ip22/ip22-reset.c > +++ b/arch/mips/sgi-ip22/ip22-reset.c > @@ -195,7 +195,7 @@ static int __init reboot_setup(void) > } > > timer_setup(&blink_timer, blink_timeout, 0); > - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); > + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); This notifier enables blinking. It is not much safe. It calls mod_timer() that takes a lock internally. This kind of functionality should go into the last list called before panic() enters the infinite loop. IMHO, all the blinking stuff should go there. > > return 0; > } > diff --git a/arch/mips/sgi-ip32/ip32-reset.c b/arch/mips/sgi-ip32/ip32-reset.c > index 18d1c115cd53..9ee1302c9d13 100644 > --- a/arch/mips/sgi-ip32/ip32-reset.c > +++ b/arch/mips/sgi-ip32/ip32-reset.c > @@ -145,7 +144,7 @@ static __init int ip32_reboot_setup(void) > pm_power_off = ip32_machine_halt; > > timer_setup(&blink_timer, blink_timeout, 0); > - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); > + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); Same here. Should be done only before the "loop". > > return 0; > } > --- a/drivers/firmware/google/gsmi.c > +++ b/drivers/firmware/google/gsmi.c > @@ -1034,7 +1034,7 @@ static __init int gsmi_init(void) > > register_reboot_notifier(&gsmi_reboot_notifier); > register_die_notifier(&gsmi_die_notifier); > - atomic_notifier_chain_register(&panic_notifier_list, > + atomic_notifier_chain_register(&panic_hypervisor_list, > &gsmi_panic_notifier); I am not sure about this one. It looks like some logging or pre_reboot stuff. > > printk(KERN_INFO "gsmi version " DRIVER_VERSION " loaded\n"); > --- a/drivers/leds/trigger/ledtrig-activity.c > +++ b/drivers/leds/trigger/ledtrig-activity.c > @@ -247,7 +247,7 @@ static int __init activity_init(void) > int rc = led_trigger_register(&activity_led_trigger); > > if (!rc) { > - atomic_notifier_chain_register(&panic_notifier_list, > + atomic_notifier_chain_register(&panic_hypervisor_list, > &activity_panic_nb); The notifier is trivial. It just sets a variable. But still, it is about blinking and should be done in the last "loop" list. > register_reboot_notifier(&activity_reboot_nb); > } > --- a/drivers/leds/trigger/ledtrig-heartbeat.c > +++ b/drivers/leds/trigger/ledtrig-heartbeat.c > @@ -190,7 +190,7 @@ static int __init heartbeat_trig_init(void) > int rc = led_trigger_register(&heartbeat_led_trigger); > > if (!rc) { > - atomic_notifier_chain_register(&panic_notifier_list, > + atomic_notifier_chain_register(&panic_hypervisor_list, > &heartbeat_panic_nb); Same here. Blinking => loop list. > register_reboot_notifier(&heartbeat_reboot_nb); > } > diff --git a/drivers/misc/bcm-vk/bcm_vk_dev.c b/drivers/misc/bcm-vk/bcm_vk_dev.c > index a16b99bdaa13..d9d5199cdb2b 100644 > --- a/drivers/misc/bcm-vk/bcm_vk_dev.c > +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c > @@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > > /* register for panic notifier */ > vk->panic_nb.notifier_call = bcm_vk_on_panic; > - err = atomic_notifier_chain_register(&panic_notifier_list, > + err = atomic_notifier_chain_register(&panic_hypervisor_list, > &vk->panic_nb); It seems to reset some hardware or so. IMHO, it should go into the pre-reboot list. > if (err) { > dev_err(dev, "Fail to register panic notifier\n"); > --- a/drivers/power/reset/ltc2952-poweroff.c > +++ b/drivers/power/reset/ltc2952-poweroff.c > @@ -279,7 +279,7 @@ static int ltc2952_poweroff_probe(struct platform_device *pdev) > pm_power_off = ltc2952_poweroff_kill; > > data->panic_notifier.notifier_call = ltc2952_poweroff_notify_panic; > - atomic_notifier_chain_register(&panic_notifier_list, > + atomic_notifier_chain_register(&panic_hypervisor_list, > &data->panic_notifier); I looks like this somehow triggers the reboot. IMHO, it should go into the pre_reboot list. > dev_info(&pdev->dev, "probe successful\n"); > > --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c > +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > @@ -814,7 +814,7 @@ static int brcmstb_pm_probe(struct platform_device *pdev) > goto out; > } > > - atomic_notifier_chain_register(&panic_notifier_list, > + atomic_notifier_chain_register(&panic_hypervisor_list, > &brcmstb_pm_panic_nb); I am not sure about this one. It instruct some HW to preserve DRAM. IMHO, it better fits into pre_reboot category but I do not have strong opinion. > > pm_power_off = brcmstb_pm_poweroff; Best Regards, Petr
Thanks for the review! I agree with the blinking stuff, I can rework and add all LED/blinking stuff into the loop list, it does make sense. I'll comment a bit in the others below... On 16/05/2022 11:01, Petr Mladek wrote: > [...] >> --- a/arch/mips/sgi-ip22/ip22-reset.c >> +++ b/arch/mips/sgi-ip22/ip22-reset.c >> @@ -195,7 +195,7 @@ static int __init reboot_setup(void) >> } >> >> timer_setup(&blink_timer, blink_timeout, 0); >> - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); >> + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); > > This notifier enables blinking. It is not much safe. It calls > mod_timer() that takes a lock internally. > > This kind of functionality should go into the last list called > before panic() enters the infinite loop. IMHO, all the blinking > stuff should go there. > [...] >> --- a/arch/mips/sgi-ip32/ip32-reset.c >> +++ b/arch/mips/sgi-ip32/ip32-reset.c >> @@ -145,7 +144,7 @@ static __init int ip32_reboot_setup(void) >> pm_power_off = ip32_machine_halt; >> >> timer_setup(&blink_timer, blink_timeout, 0); >> - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); >> + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); > > Same here. Should be done only before the "loop". > [...] Ack. >> --- a/drivers/firmware/google/gsmi.c >> +++ b/drivers/firmware/google/gsmi.c >> @@ -1034,7 +1034,7 @@ static __init int gsmi_init(void) >> >> register_reboot_notifier(&gsmi_reboot_notifier); >> register_die_notifier(&gsmi_die_notifier); >> - atomic_notifier_chain_register(&panic_notifier_list, >> + atomic_notifier_chain_register(&panic_hypervisor_list, >> &gsmi_panic_notifier); > > I am not sure about this one. It looks like some logging or > pre_reboot stuff. > Disagree here. I'm looping Google maintainers, so they can comment. (CCed Evan, David, Julius) This notifier is clearly a hypervisor notification mechanism. I've fixed a locking stuff there (in previous patch), I feel it's low-risk but even if it's mid-risk, the class of such callback remains a perfect fit with the hypervisor list IMHO. > [...] >> --- a/drivers/leds/trigger/ledtrig-activity.c >> +++ b/drivers/leds/trigger/ledtrig-activity.c >> @@ -247,7 +247,7 @@ static int __init activity_init(void) >> int rc = led_trigger_register(&activity_led_trigger); >> >> if (!rc) { >> - atomic_notifier_chain_register(&panic_notifier_list, >> + atomic_notifier_chain_register(&panic_hypervisor_list, >> &activity_panic_nb); > > The notifier is trivial. It just sets a variable. > > But still, it is about blinking and should be done > in the last "loop" list. > > >> register_reboot_notifier(&activity_reboot_nb); >> } >> --- a/drivers/leds/trigger/ledtrig-heartbeat.c >> +++ b/drivers/leds/trigger/ledtrig-heartbeat.c >> @@ -190,7 +190,7 @@ static int __init heartbeat_trig_init(void) >> int rc = led_trigger_register(&heartbeat_led_trigger); >> >> if (!rc) { >> - atomic_notifier_chain_register(&panic_notifier_list, >> + atomic_notifier_chain_register(&panic_hypervisor_list, >> &heartbeat_panic_nb); > > Same here. Blinking => loop list. Ack. >> [...] >> diff --git a/drivers/misc/bcm-vk/bcm_vk_dev.c b/drivers/misc/bcm-vk/bcm_vk_dev.c >> index a16b99bdaa13..d9d5199cdb2b 100644 >> --- a/drivers/misc/bcm-vk/bcm_vk_dev.c >> +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c >> @@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const struct pci_device_id *ent) >> >> /* register for panic notifier */ >> vk->panic_nb.notifier_call = bcm_vk_on_panic; >> - err = atomic_notifier_chain_register(&panic_notifier_list, >> + err = atomic_notifier_chain_register(&panic_hypervisor_list, >> &vk->panic_nb); > > It seems to reset some hardware or so. IMHO, it should go into the > pre-reboot list. Mixed feelings here, I'm looping Broadcom maintainers to comment. (CC Scott and Broadcom list) I'm afraid it breaks kdump if this device is not reset beforehand - it's a doorbell write, so not high risk I think... But in case the not-reset device can be probed normally in kdump kernel, then I'm fine in moving this to the reboot list! I don't have the HW to test myself. > [...] >> --- a/drivers/power/reset/ltc2952-poweroff.c >> +++ b/drivers/power/reset/ltc2952-poweroff.c >> @@ -279,7 +279,7 @@ static int ltc2952_poweroff_probe(struct platform_device *pdev) >> pm_power_off = ltc2952_poweroff_kill; >> >> data->panic_notifier.notifier_call = ltc2952_poweroff_notify_panic; >> - atomic_notifier_chain_register(&panic_notifier_list, >> + atomic_notifier_chain_register(&panic_hypervisor_list, >> &data->panic_notifier); > > I looks like this somehow triggers the reboot. IMHO, it should go > into the pre_reboot list. Mixed feeling again here - CCing the maintainers for comments (Sebastian / PM folks). This is setting a variable only, and once it's set (data->kernel_panic is the bool's name), it just bails out the IRQ handler and a timer setting - this timer seems kinda tricky, so bailing out ASAP makes sense IMHO. But my mixed feeling comes from the fact this notifier really is not a fit to any list - it's just a "watchdog"/device quiesce in some form. Since it's very low-risk (IIUC), I've put it here. > [...] >> --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c >> +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c >> @@ -814,7 +814,7 @@ static int brcmstb_pm_probe(struct platform_device *pdev) >> goto out; >> } >> >> - atomic_notifier_chain_register(&panic_notifier_list, >> + atomic_notifier_chain_register(&panic_hypervisor_list, >> &brcmstb_pm_panic_nb); > > I am not sure about this one. It instruct some HW to preserve DRAM. > IMHO, it better fits into pre_reboot category but I do not have > strong opinion. Disagree here, I'm CCing Florian for information. This notifier preserves RAM so it's *very interesting* if we have kmsg_dump() for example, but maybe might be also relevant in case kdump kernel is configured to store something in a persistent RAM (then, without this notifier, after kdump reboots the system data would be lost). Cheers, Guilherme
On Mon, May 16, 2022 at 8:07 AM Guilherme G. Piccoli <gpiccoli@igalia.com> wrote: > > Thanks for the review! > > I agree with the blinking stuff, I can rework and add all LED/blinking > stuff into the loop list, it does make sense. I'll comment a bit in the > others below... > > On 16/05/2022 11:01, Petr Mladek wrote: > > [...] > >> --- a/arch/mips/sgi-ip22/ip22-reset.c > >> +++ b/arch/mips/sgi-ip22/ip22-reset.c > >> @@ -195,7 +195,7 @@ static int __init reboot_setup(void) > >> } > >> > >> timer_setup(&blink_timer, blink_timeout, 0); > >> - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); > >> + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); > > > > This notifier enables blinking. It is not much safe. It calls > > mod_timer() that takes a lock internally. > > > > This kind of functionality should go into the last list called > > before panic() enters the infinite loop. IMHO, all the blinking > > stuff should go there. > > [...] > >> --- a/arch/mips/sgi-ip32/ip32-reset.c > >> +++ b/arch/mips/sgi-ip32/ip32-reset.c > >> @@ -145,7 +144,7 @@ static __init int ip32_reboot_setup(void) > >> pm_power_off = ip32_machine_halt; > >> > >> timer_setup(&blink_timer, blink_timeout, 0); > >> - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); > >> + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); > > > > Same here. Should be done only before the "loop". > > [...] > > Ack. > > > >> --- a/drivers/firmware/google/gsmi.c > >> +++ b/drivers/firmware/google/gsmi.c > >> @@ -1034,7 +1034,7 @@ static __init int gsmi_init(void) > >> > >> register_reboot_notifier(&gsmi_reboot_notifier); > >> register_die_notifier(&gsmi_die_notifier); > >> - atomic_notifier_chain_register(&panic_notifier_list, > >> + atomic_notifier_chain_register(&panic_hypervisor_list, > >> &gsmi_panic_notifier); > > > > I am not sure about this one. It looks like some logging or > > pre_reboot stuff. > > > > Disagree here. I'm looping Google maintainers, so they can comment. > (CCed Evan, David, Julius) > > This notifier is clearly a hypervisor notification mechanism. I've fixed > a locking stuff there (in previous patch), I feel it's low-risk but even > if it's mid-risk, the class of such callback remains a perfect fit with > the hypervisor list IMHO. This logs a panic to our "eventlog", a tiny logging area in SPI flash for critical and power-related events. In some cases this ends up being the only clue we get in a Chromebook feedback report that a panic occurred, so from my perspective moving it to the front of the line seems like a good idea. -Evan
On Mon 2022-05-16 09:02:10, Evan Green wrote: > On Mon, May 16, 2022 at 8:07 AM Guilherme G. Piccoli > <gpiccoli@igalia.com> wrote: > > > > Thanks for the review! > > > > I agree with the blinking stuff, I can rework and add all LED/blinking > > stuff into the loop list, it does make sense. I'll comment a bit in the > > others below... > > > > On 16/05/2022 11:01, Petr Mladek wrote: > > > [...] > > >> --- a/arch/mips/sgi-ip22/ip22-reset.c > > >> +++ b/arch/mips/sgi-ip22/ip22-reset.c > > >> @@ -195,7 +195,7 @@ static int __init reboot_setup(void) > > >> } > > >> > > >> timer_setup(&blink_timer, blink_timeout, 0); > > >> - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); > > >> + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); > > > > > > This notifier enables blinking. It is not much safe. It calls > > > mod_timer() that takes a lock internally. > > > > > > This kind of functionality should go into the last list called > > > before panic() enters the infinite loop. IMHO, all the blinking > > > stuff should go there. > > > [...] > > >> --- a/arch/mips/sgi-ip32/ip32-reset.c > > >> +++ b/arch/mips/sgi-ip32/ip32-reset.c > > >> @@ -145,7 +144,7 @@ static __init int ip32_reboot_setup(void) > > >> pm_power_off = ip32_machine_halt; > > >> > > >> timer_setup(&blink_timer, blink_timeout, 0); > > >> - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); > > >> + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); > > > > > > Same here. Should be done only before the "loop". > > > [...] > > > > Ack. > > > > > > >> --- a/drivers/firmware/google/gsmi.c > > >> +++ b/drivers/firmware/google/gsmi.c > > >> @@ -1034,7 +1034,7 @@ static __init int gsmi_init(void) > > >> > > >> register_reboot_notifier(&gsmi_reboot_notifier); > > >> register_die_notifier(&gsmi_die_notifier); > > >> - atomic_notifier_chain_register(&panic_notifier_list, > > >> + atomic_notifier_chain_register(&panic_hypervisor_list, > > >> &gsmi_panic_notifier); > > > > > > I am not sure about this one. It looks like some logging or > > > pre_reboot stuff. > > > > > > > Disagree here. I'm looping Google maintainers, so they can comment. > > (CCed Evan, David, Julius) > > > > This notifier is clearly a hypervisor notification mechanism. I've fixed > > a locking stuff there (in previous patch), I feel it's low-risk but even > > if it's mid-risk, the class of such callback remains a perfect fit with > > the hypervisor list IMHO. > > This logs a panic to our "eventlog", a tiny logging area in SPI flash > for critical and power-related events. In some cases this ends up > being the only clue we get in a Chromebook feedback report that a > panic occurred, so from my perspective moving it to the front of the > line seems like a good idea. IMHO, this would really better fit into the pre-reboot notifier list: + the callback stores the log so it is similar to kmsg_dump() or console_flush_on_panic() + the callback should be proceed after "info" notifiers that might add some other useful information. Honestly, I am not sure what exactly hypervisor callbacks do. But I think that they do not try to extract the kernel log because they would need to handle the internal format. Best Regards, Petr
On Mon 2022-05-16 12:06:17, Guilherme G. Piccoli wrote: > Thanks for the review! > > I agree with the blinking stuff, I can rework and add all LED/blinking > stuff into the loop list, it does make sense. I'll comment a bit in the > others below... > > On 16/05/2022 11:01, Petr Mladek wrote: > >> --- a/drivers/firmware/google/gsmi.c > >> +++ b/drivers/firmware/google/gsmi.c > >> @@ -1034,7 +1034,7 @@ static __init int gsmi_init(void) > >> > >> register_reboot_notifier(&gsmi_reboot_notifier); > >> register_die_notifier(&gsmi_die_notifier); > >> - atomic_notifier_chain_register(&panic_notifier_list, > >> + atomic_notifier_chain_register(&panic_hypervisor_list, > >> &gsmi_panic_notifier); > > > > I am not sure about this one. It looks like some logging or > > pre_reboot stuff. > > > > Disagree here. I'm looping Google maintainers, so they can comment. > (CCed Evan, David, Julius) > > This notifier is clearly a hypervisor notification mechanism. I've fixed > a locking stuff there (in previous patch), I feel it's low-risk but even > if it's mid-risk, the class of such callback remains a perfect fit with > the hypervisor list IMHO. It is similar to drivers/soc/bcm/brcmstb/pm/pm-arm.c. See below for another idea. > >> --- a/drivers/misc/bcm-vk/bcm_vk_dev.c > >> +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c > >> @@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > >> > >> /* register for panic notifier */ > >> vk->panic_nb.notifier_call = bcm_vk_on_panic; > >> - err = atomic_notifier_chain_register(&panic_notifier_list, > >> + err = atomic_notifier_chain_register(&panic_hypervisor_list, > >> &vk->panic_nb); > > > > It seems to reset some hardware or so. IMHO, it should go into the > > pre-reboot list. > > Mixed feelings here, I'm looping Broadcom maintainers to comment. > (CC Scott and Broadcom list) > > I'm afraid it breaks kdump if this device is not reset beforehand - it's > a doorbell write, so not high risk I think... > > But in case the not-reset device can be probed normally in kdump kernel, > then I'm fine in moving this to the reboot list! I don't have the HW to > test myself. Good question. Well, it if has to be called before kdump then even "hypervisor" list is a wrong place because is not always called before kdump. > >> --- a/drivers/power/reset/ltc2952-poweroff.c > >> +++ b/drivers/power/reset/ltc2952-poweroff.c > >> @@ -279,7 +279,7 @@ static int ltc2952_poweroff_probe(struct platform_device *pdev) > >> pm_power_off = ltc2952_poweroff_kill; > >> > >> data->panic_notifier.notifier_call = ltc2952_poweroff_notify_panic; > >> - atomic_notifier_chain_register(&panic_notifier_list, > >> + atomic_notifier_chain_register(&panic_hypervisor_list, > >> &data->panic_notifier); > > > > I looks like this somehow triggers the reboot. IMHO, it should go > > into the pre_reboot list. > > Mixed feeling again here - CCing the maintainers for comments (Sebastian > / PM folks). > > This is setting a variable only, and once it's set (data->kernel_panic > is the bool's name), it just bails out the IRQ handler and a timer > setting - this timer seems kinda tricky, so bailing out ASAP makes sense > IMHO. IMHO, the timer informs the hardware that the system is still alive in the middle of panic(). If the timer is not working then the hardware (chip) will think that the system frozen in panic() and will power off the system. See the comments in drivers/power/reset/ltc2952-poweroff.c: * The following GPIOs are used: * - trigger (input) * A level change indicates the shut-down trigger. If it's state reverts * within the time-out defined by trigger_delay, the shut down is not * executed. If no pin is assigned to this input, the driver will start the * watchdog toggle immediately. The chip will only power off the system if * it is requested to do so through the kill line. * * - watchdog (output) * Once a shut down is triggered, the driver will toggle this signal, * with an internal (wde_interval) to stall the hardware shut down. IMHO, we really have to keep it alive until we reach the reboot stage. Another question is how it actually works when the interrupts are disabled during panic() and the timer callbacks are not handled. > > [...] > >> --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c > >> +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > >> @@ -814,7 +814,7 @@ static int brcmstb_pm_probe(struct platform_device *pdev) > >> goto out; > >> } > >> > >> - atomic_notifier_chain_register(&panic_notifier_list, > >> + atomic_notifier_chain_register(&panic_hypervisor_list, > >> &brcmstb_pm_panic_nb); > > > > I am not sure about this one. It instruct some HW to preserve DRAM. > > IMHO, it better fits into pre_reboot category but I do not have > > strong opinion. > > Disagree here, I'm CCing Florian for information. > > This notifier preserves RAM so it's *very interesting* if we have > kmsg_dump() for example, but maybe might be also relevant in case kdump > kernel is configured to store something in a persistent RAM (then, > without this notifier, after kdump reboots the system data would be lost). I see. It is actually similar problem as with drivers/firmware/google/gsmi.c. I does similar things like kmsg_dump() so it should be called in the same location (after info notifier list and before kdump). A solution might be to put it at these notifiers at the very end of the "info" list or make extra "dump" notifier list. Best Regards, Petr
On 17/05/2022 10:28, Petr Mladek wrote: > [...] >>> Disagree here. I'm looping Google maintainers, so they can comment. >>> (CCed Evan, David, Julius) >>> >>> This notifier is clearly a hypervisor notification mechanism. I've fixed >>> a locking stuff there (in previous patch), I feel it's low-risk but even >>> if it's mid-risk, the class of such callback remains a perfect fit with >>> the hypervisor list IMHO. >> >> This logs a panic to our "eventlog", a tiny logging area in SPI flash >> for critical and power-related events. In some cases this ends up >> being the only clue we get in a Chromebook feedback report that a >> panic occurred, so from my perspective moving it to the front of the >> line seems like a good idea. > > IMHO, this would really better fit into the pre-reboot notifier list: > > + the callback stores the log so it is similar to kmsg_dump() > or console_flush_on_panic() > > + the callback should be proceed after "info" notifiers > that might add some other useful information. > > Honestly, I am not sure what exactly hypervisor callbacks do. But I > think that they do not try to extract the kernel log because they > would need to handle the internal format. > I guess the main point in your response is : "I am not sure what exactly hypervisor callbacks do". We need to be sure about the semantics of such list, and agree on that. So, my opinion about this first list, that we call "hypervisor list", is: it contains callbacks that (1) should run early, preferably before kdump (or even if kdump isn't set, should run ASAP); (2) these callbacks perform some communication with an abstraction that runs "below" the kernel, like a firmware or hypervisor. Classic example: pvpanic, that communicates with VMM (usually qemu) and allow such VMM to snapshot the full guest memory, for example. (3) Should be low-risk. What defines risk is the level of reliability of subsequent operations - if the callback have 50% of chance of "bricking" the system totally and prevent kdump / kmsg_dump() / reboot , this is high risk one for example. Some good fits IMO: pvpanic, sstate_panic_event() [sparc], fadump in powerpc, etc. So, this is a good case for the Google notifier as well - it's not collecting data like the dmesg (hence your second bullet seems to not apply here, info notifiers won't add info to be collected by gsmi). It is a firmware/hypervisor/whatever-gsmi-is notification mechanism, that tells such "lower" abstraction a panic occurred. It seems low risk and we want it to run ASAP, if possible. So, I'd like to keep it here, unless gsmi maintainers disagree or I'm perhaps misunderstanding the meaning of this first list. Cheers, Guilherme
On 17/05/2022 10:57, Petr Mladek wrote: > [...] >>>> --- a/drivers/misc/bcm-vk/bcm_vk_dev.c >>>> +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c >>>> @@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const struct pci_device_id *ent) >>> [... snip ...] >>> It seems to reset some hardware or so. IMHO, it should go into the >>> pre-reboot list. >> >> Mixed feelings here, I'm looping Broadcom maintainers to comment. >> (CC Scott and Broadcom list) >> >> I'm afraid it breaks kdump if this device is not reset beforehand - it's >> a doorbell write, so not high risk I think... >> >> But in case the not-reset device can be probed normally in kdump kernel, >> then I'm fine in moving this to the reboot list! I don't have the HW to >> test myself. > > Good question. Well, it if has to be called before kdump then > even "hypervisor" list is a wrong place because is not always > called before kdump. Agreed! I'll defer that to Scott and Broadcom folks to comment. If it's not strictly necessary, I'll happily move it to the reboot list. If necessary, we could use the machine_crash_kexec() approach, but we'll fall into the case arm64 doesn't support it and I'm not sure if this device is available for arm - again a question for the maintainers. > [...] >>>> --- a/drivers/power/reset/ltc2952-poweroff.c >>>> +++ b/drivers/power/reset/ltc2952-poweroff.c >> [...] >> This is setting a variable only, and once it's set (data->kernel_panic >> is the bool's name), it just bails out the IRQ handler and a timer >> setting - this timer seems kinda tricky, so bailing out ASAP makes sense >> IMHO. > > IMHO, the timer informs the hardware that the system is still alive > in the middle of panic(). If the timer is not working then the > hardware (chip) will think that the system frozen in panic() > and will power off the system. See the comments in > drivers/power/reset/ltc2952-poweroff.c: > [.... snip ...] > IMHO, we really have to keep it alive until we reach the reboot stage. > > Another question is how it actually works when the interrupts are > disabled during panic() and the timer callbacks are not handled. Agreed here! Guess I can move this one the reboot list, fine by me. Unless PM folks think otherwise. > [...] >> Disagree here, I'm CCing Florian for information. >> >> This notifier preserves RAM so it's *very interesting* if we have >> kmsg_dump() for example, but maybe might be also relevant in case kdump >> kernel is configured to store something in a persistent RAM (then, >> without this notifier, after kdump reboots the system data would be lost). > > I see. It is actually similar problem as with > drivers/firmware/google/gsmi.c. > > I does similar things like kmsg_dump() so it should be called in > the same location (after info notifier list and before kdump). > > A solution might be to put it at these notifiers at the very > end of the "info" list or make extra "dump" notifier list. Here I still disagree. I've commented in the other response thread (about Google gsmi) about the semantics of the hypervisor list, but again: this list should contain callbacks that (a) Should run early, _by default_ before a kdump; (b) Communicate with the firmware/hypervisor in a "low-risk" way; Imagine a scenario where users configure kdump kernel to save something in a persistent form in DRAM - it'd be like a late pstore, in the next kernel. This callback enables that, it's meant to inform FW "hey, panic happened, please from now on don't clear the RAM in the next FW-reboot". I don't see a reason to postpone that - let's see if the maintainers have an opinion. Cheers, Guilherme
On Tue 2022-05-17 13:37:58, Guilherme G. Piccoli wrote: > On 17/05/2022 10:28, Petr Mladek wrote: > > [...] > >>> Disagree here. I'm looping Google maintainers, so they can comment. > >>> (CCed Evan, David, Julius) > >>> > >>> This notifier is clearly a hypervisor notification mechanism. I've fixed > >>> a locking stuff there (in previous patch), I feel it's low-risk but even > >>> if it's mid-risk, the class of such callback remains a perfect fit with > >>> the hypervisor list IMHO. > >> > >> This logs a panic to our "eventlog", a tiny logging area in SPI flash > >> for critical and power-related events. In some cases this ends up > >> being the only clue we get in a Chromebook feedback report that a > >> panic occurred, so from my perspective moving it to the front of the > >> line seems like a good idea. > > > > IMHO, this would really better fit into the pre-reboot notifier list: > > > > + the callback stores the log so it is similar to kmsg_dump() > > or console_flush_on_panic() > > > > + the callback should be proceed after "info" notifiers > > that might add some other useful information. > > > > Honestly, I am not sure what exactly hypervisor callbacks do. But I > > think that they do not try to extract the kernel log because they > > would need to handle the internal format. > > > > I guess the main point in your response is : "I am not sure what exactly > hypervisor callbacks do". We need to be sure about the semantics of such > list, and agree on that. > > So, my opinion about this first list, that we call "hypervisor list", > is: it contains callbacks that > > (1) should run early, preferably before kdump (or even if kdump isn't > set, should run ASAP); > > (2) these callbacks perform some communication with an abstraction that > runs "below" the kernel, like a firmware or hypervisor. Classic example: > pvpanic, that communicates with VMM (usually qemu) and allow such VMM to > snapshot the full guest memory, for example. > > (3) Should be low-risk. What defines risk is the level of reliability of > subsequent operations - if the callback have 50% of chance of "bricking" > the system totally and prevent kdump / kmsg_dump() / reboot , this is > high risk one for example. > > Some good fits IMO: pvpanic, sstate_panic_event() [sparc], fadump in > powerpc, etc. > > So, this is a good case for the Google notifier as well - it's not > collecting data like the dmesg (hence your second bullet seems to not > apply here, info notifiers won't add info to be collected by gsmi). It > is a firmware/hypervisor/whatever-gsmi-is notification mechanism, that > tells such "lower" abstraction a panic occurred. It seems low risk and > we want it to run ASAP, if possible. " > >> This logs a panic to our "eventlog", a tiny logging area in SPI flash > >> for critical and power-related events. In some cases this ends up I see. I somehow assumed that it was about the kernel log because Evans wrote: "This logs a panic to our "eventlog", a tiny logging area in SPI flash for critical and power-related events. In some cases this ends up" Anyway, I would distinguish it the following way. + If the notifier is preserving kernel log then it should be ideally treated as kmsg_dump(). + It the notifier is saving another debugging data then it better fits into the "hypervisor" notifier list. Regarding the reliability. From my POV, any panic notifier enabled in a generic kernel should be reliable with more than 99,9%. Otherwise, they should not be in the notifier list at all. An exception would be a platform-specific notifier that is called only on some specific platform and developers maintaining this platform agree on this. The value "99,9%" is arbitrary. I am not sure if it is realistic even in the other code, for example, console_flush_on_panic() or emergency_restart(). I just want to point out that the border should be rather high. Otherwise we would back in the situation where people would want to disable particular notifiers. Best Regards, Petr
On 18/05/2022 04:38, Petr Mladek wrote: > [...] > I have answered this in more detail in the other reply, see > https://lore.kernel.org/r/YoShZVYNAdvvjb7z@alley > > I agree that both notifiers in > > drivers/soc/bcm/brcmstb/pm/pm-arm.c > drivers/firmware/google/gsmi.c > > better fit into the hypervisor list after all. > > Best Regards, > Petr Perfect, thanks - will keep both in such list for V2.
On 18/05/2022 04:58, Petr Mladek wrote: > [...] >> I does similar things like kmsg_dump() so it should be called in >> the same location (after info notifier list and before kdump). >> >> A solution might be to put it at these notifiers at the very >> end of the "info" list or make extra "dump" notifier list. > > I just want to point out that the above idea has problems. > Notifiers storing kernel log need to be treated as kmsg_dump(). > In particular, we would need to know if there are any. > We do not need to call "info" notifier list before kdump > when there is no kernel log dumper registered. > Notifiers respect the priority concept, which is just a number that orders the list addition (and the list is called in order). I've used the last position to panic_print() [in patch 25] - one idea here is to "reserve" the last position (represented by INT_MIN) for notifiers that act like kmsg_dump(). I couldn't find any IIRC, but that doesn't prevent us to save this position and comment about that. Makes sense to you ? Cheers!
On 18/05/2022 04:33, Petr Mladek wrote: > [...] > Anyway, I would distinguish it the following way. > > + If the notifier is preserving kernel log then it should be ideally > treated as kmsg_dump(). > > + It the notifier is saving another debugging data then it better > fits into the "hypervisor" notifier list. > > Definitely, I agree - it's logical, since we want more info in the logs, and happens some notifiers running in the informational list do that, like ftrace_on_oops for example. > Regarding the reliability. From my POV, any panic notifier enabled > in a generic kernel should be reliable with more than 99,9%. > Otherwise, they should not be in the notifier list at all. > > An exception would be a platform-specific notifier that is > called only on some specific platform and developers maintaining > this platform agree on this. > > The value "99,9%" is arbitrary. I am not sure if it is realistic > even in the other code, for example, console_flush_on_panic() > or emergency_restart(). I just want to point out that the border > should be rather high. Otherwise we would back in the situation > where people would want to disable particular notifiers. > Totally agree, these percentages are just an example, 50% is ridiculous low reliability in my example heheh But some notifiers deep dive in abstraction layers (like regmap or GPIO stuff) and it's hard to determine the probability of a lock issue (take a spinlock already taken inside regmap code and live-lock forever, for example). These are better to run, if possible, later than kdump or even info list. Thanks again for the good analysis Petr! Cheers, Guilherme
Hi Guilherme, +Desmond On 2022-05-17 09:42, Guilherme G. Piccoli wrote: > On 17/05/2022 10:57, Petr Mladek wrote: >> [...] >>>>> --- a/drivers/misc/bcm-vk/bcm_vk_dev.c >>>>> +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c >>>>> @@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const struct pci_device_id *ent) >>>> [... snip ...] >>>> It seems to reset some hardware or so. IMHO, it should go into the >>>> pre-reboot list. >>> >>> Mixed feelings here, I'm looping Broadcom maintainers to comment. >>> (CC Scott and Broadcom list) >>> >>> I'm afraid it breaks kdump if this device is not reset beforehand - it's >>> a doorbell write, so not high risk I think... >>> >>> But in case the not-reset device can be probed normally in kdump kernel, >>> then I'm fine in moving this to the reboot list! I don't have the HW to >>> test myself. >> >> Good question. Well, it if has to be called before kdump then >> even "hypervisor" list is a wrong place because is not always >> called before kdump. > > Agreed! I'll defer that to Scott and Broadcom folks to comment. > If it's not strictly necessary, I'll happily move it to the reboot list. > > If necessary, we could use the machine_crash_kexec() approach, but we'll > fall into the case arm64 doesn't support it and I'm not sure if this > device is available for arm - again a question for the maintainers. We register to the panic notifier so that we can kill the VK card ASAP to stop DMAing things over to the host side. If it is not notified then memory may not be frozen when kdump is occurring. Notifying the card on panic is also needed to allow for any type of reset to occur. So, the only thing preventing moving the notifier later is the chance that memory is modified while kdump is occurring. Or, if DMA is disabled before kdump already then this wouldn't be an issue and the notification to the card (to allow for clean resets) can be done later. > > >> [...] >>>>> --- a/drivers/power/reset/ltc2952-poweroff.c >>>>> +++ b/drivers/power/reset/ltc2952-poweroff.c >>> [...] >>> This is setting a variable only, and once it's set (data->kernel_panic >>> is the bool's name), it just bails out the IRQ handler and a timer >>> setting - this timer seems kinda tricky, so bailing out ASAP makes sense >>> IMHO. >> >> IMHO, the timer informs the hardware that the system is still alive >> in the middle of panic(). If the timer is not working then the >> hardware (chip) will think that the system frozen in panic() >> and will power off the system. See the comments in >> drivers/power/reset/ltc2952-poweroff.c: >> [.... snip ...] >> IMHO, we really have to keep it alive until we reach the reboot stage. >> >> Another question is how it actually works when the interrupts are >> disabled during panic() and the timer callbacks are not handled. > > Agreed here! Guess I can move this one the reboot list, fine by me. > Unless PM folks think otherwise. > > >> [...] >>> Disagree here, I'm CCing Florian for information. >>> >>> This notifier preserves RAM so it's *very interesting* if we have >>> kmsg_dump() for example, but maybe might be also relevant in case kdump >>> kernel is configured to store something in a persistent RAM (then, >>> without this notifier, after kdump reboots the system data would be lost). >> >> I see. It is actually similar problem as with >> drivers/firmware/google/gsmi.c. >> >> I does similar things like kmsg_dump() so it should be called in >> the same location (after info notifier list and before kdump). >> >> A solution might be to put it at these notifiers at the very >> end of the "info" list or make extra "dump" notifier list. > > Here I still disagree. I've commented in the other response thread > (about Google gsmi) about the semantics of the hypervisor list, but > again: this list should contain callbacks that > > (a) Should run early, _by default_ before a kdump; > (b) Communicate with the firmware/hypervisor in a "low-risk" way; > > Imagine a scenario where users configure kdump kernel to save something > in a persistent form in DRAM - it'd be like a late pstore, in the next > kernel. This callback enables that, it's meant to inform FW "hey, panic > happened, please from now on don't clear the RAM in the next FW-reboot". > I don't see a reason to postpone that - let's see if the maintainers > have an opinion. > > Cheers, > > > Guilherme
On Wed 2022-05-18 10:16:20, Guilherme G. Piccoli wrote: > On 18/05/2022 04:58, Petr Mladek wrote: > > [...] > >> I does similar things like kmsg_dump() so it should be called in > >> the same location (after info notifier list and before kdump). > >> > >> A solution might be to put it at these notifiers at the very > >> end of the "info" list or make extra "dump" notifier list. > > > > I just want to point out that the above idea has problems. > > Notifiers storing kernel log need to be treated as kmsg_dump(). > > In particular, we would need to know if there are any. > > We do not need to call "info" notifier list before kdump > > when there is no kernel log dumper registered. > > > > Notifiers respect the priority concept, which is just a number that > orders the list addition (and the list is called in order). > > I've used the last position to panic_print() [in patch 25] - one idea > here is to "reserve" the last position (represented by INT_MIN) for > notifiers that act like kmsg_dump(). I couldn't find any IIRC, but that > doesn't prevent us to save this position and comment about that. I would ignore it for now. If anyone would want to safe the log then they would need to read it. They will most likely use the existing kmsg_dump() infastructure. In fact, they should use it to avoid a code duplication. Best Regards, Petr
On 19/05/2022 04:03, Petr Mladek wrote: > [...] > I would ignore it for now. If anyone would want to safe the log > then they would need to read it. They will most likely use > the existing kmsg_dump() infastructure. In fact, they should > use it to avoid a code duplication. > > Best Regards, > Petr Cool, thanks! I agree, let's expect people use kmsg_dump() as they should =)
On 18/05/2022 19:17, Scott Branden wrote: > Hi Guilherme, > > +Desmond > [...] >>>> I'm afraid it breaks kdump if this device is not reset beforehand - it's >>>> a doorbell write, so not high risk I think... >>>> >>>> But in case the not-reset device can be probed normally in kdump kernel, >>>> then I'm fine in moving this to the reboot list! I don't have the HW to >>>> test myself. >>> >>> Good question. Well, it if has to be called before kdump then >>> even "hypervisor" list is a wrong place because is not always >>> called before kdump. >> [...] > We register to the panic notifier so that we can kill the VK card ASAP > to stop DMAing things over to the host side. If it is not notified then > memory may not be frozen when kdump is occurring. > Notifying the card on panic is also needed to allow for any type of > reset to occur. > > So, the only thing preventing moving the notifier later is the chance > that memory is modified while kdump is occurring. Or, if DMA is > disabled before kdump already then this wouldn't be an issue and the > notification to the card (to allow for clean resets) can be done later. Hi Scott / Desmond, thanks for the detailed answer! Is this adapter designed to run in x86 only or you have other architectures' use cases? I'm not expert on that, but I guess whether DMA is "kept" or not depends a bit if IOMMU is used. IIRC, there was a copy of the DMAR table in kdump (at least for Intel IOMMU). Also, devices are not properly quiesced on kdump IIUC, we don't call shutdown/reset handlers, they're skip due to the crash nature - so there is a risk of devices doing bad things in the new kernel. With that said, and given this is a lightweight notifier that ideally should run ASAP, I'd keep this one in the hypervisor list. We can "adjust" the semantic of this list to include lightweight notifiers that reset adapters. With that said, Petr has a point - not always such list is going to be called before kdump. So, that makes me think in another idea: what if we have another list, but not on panic path, but instead in the custom crash_shutdown()? Drivers could add callbacks there that must execute before kexec/kdump, no matter what. Let me know your thoughts Scott / Desmond / Petr and all interested parties. Cheers, Guilherme
On 2022-05-19 05:19, Guilherme G. Piccoli wrote: > On 18/05/2022 19:17, Scott Branden wrote: >> Hi Guilherme, >> >> +Desmond >> [...] >>>>> I'm afraid it breaks kdump if this device is not reset beforehand - it's >>>>> a doorbell write, so not high risk I think... >>>>> >>>>> But in case the not-reset device can be probed normally in kdump kernel, >>>>> then I'm fine in moving this to the reboot list! I don't have the HW to >>>>> test myself. >>>> >>>> Good question. Well, it if has to be called before kdump then >>>> even "hypervisor" list is a wrong place because is not always >>>> called before kdump. >>> [...] >> We register to the panic notifier so that we can kill the VK card ASAP >> to stop DMAing things over to the host side. If it is not notified then >> memory may not be frozen when kdump is occurring. >> Notifying the card on panic is also needed to allow for any type of >> reset to occur. >> >> So, the only thing preventing moving the notifier later is the chance >> that memory is modified while kdump is occurring. Or, if DMA is >> disabled before kdump already then this wouldn't be an issue and the >> notification to the card (to allow for clean resets) can be done later. > > Hi Scott / Desmond, thanks for the detailed answer! Is this adapter > designed to run in x86 only or you have other architectures' use cases? The adapter may be used in any PCIe design that supports DMA. So it may be possible to run in arm64 servers. > > I'm not expert on that, but I guess whether DMA is "kept" or not depends > a bit if IOMMU is used. IIRC, there was a copy of the DMAR table in > kdump (at least for Intel IOMMU). Also, devices are not properly > quiesced on kdump IIUC, we don't call shutdown/reset handlers, they're > skip due to the crash nature - so there is a risk of devices doing bad > things in the new kernel. > > With that said, and given this is a lightweight notifier that ideally > should run ASAP, I'd keep this one in the hypervisor list. We can > "adjust" the semantic of this list to include lightweight notifiers that > reset adapters. Sounds the best to keep system operating as tested today. > > With that said, Petr has a point - not always such list is going to be > called before kdump. So, that makes me think in another idea: what if we > have another list, but not on panic path, but instead in the custom > crash_shutdown()? Drivers could add callbacks there that must execute > before kexec/kdump, no matter what. It may be beneficial for some other drivers but for our use we would then need to register for the panic path and the crash_shutdown path. We notify the VK card for 2 purposes: one to stop DMA so memory stop changing during a kdump. And also to get the card into a good state so resets happen cleanly. > > Let me know your thoughts Scott / Desmond / Petr and all interested parties. > Cheers, > > > Guilherme
On Mon 2022-05-23 11:56:12, Guilherme G. Piccoli wrote: > On 19/05/2022 16:20, Scott Branden wrote: > > [...] > >> Hi Scott / Desmond, thanks for the detailed answer! Is this adapter > >> designed to run in x86 only or you have other architectures' use cases? > > The adapter may be used in any PCIe design that supports DMA. > > So it may be possible to run in arm64 servers. > >> > >> [...] > >> With that said, and given this is a lightweight notifier that ideally > >> should run ASAP, I'd keep this one in the hypervisor list. We can > >> "adjust" the semantic of this list to include lightweight notifiers that > >> reset adapters. > > Sounds the best to keep system operating as tested today. > >> > >> With that said, Petr has a point - not always such list is going to be > >> called before kdump. So, that makes me think in another idea: what if we > >> have another list, but not on panic path, but instead in the custom > >> crash_shutdown()? Drivers could add callbacks there that must execute > >> before kexec/kdump, no matter what. > > It may be beneficial for some other drivers but for our use we would > > then need to register for the panic path and the crash_shutdown path. > > We notify the VK card for 2 purposes: one to stop DMA so memory stop > > changing during a kdump. And also to get the card into a good state so > > resets happen cleanly. > > Thanks Scott! With that, I guess it's really better to keep this > notifier in this hypervisor/early list - I'm planning to do that for V2. > Unless Petr or somebody has strong feelings against that, of course. I am fine with it because we do not have a better solution at the moment. It might be a good candidate for the 5th notifier list mentioned in the thread https://lore.kernel.org/r/YoyQyHHfhIIXSX0U@alley . But I am not sure if the 5th list is worth the complexity. Best Regards, Petr
diff --git a/arch/mips/sgi-ip22/ip22-reset.c b/arch/mips/sgi-ip22/ip22-reset.c index 8f0861c58080..3023848acbf1 100644 --- a/arch/mips/sgi-ip22/ip22-reset.c +++ b/arch/mips/sgi-ip22/ip22-reset.c @@ -195,7 +195,7 @@ static int __init reboot_setup(void) } timer_setup(&blink_timer, blink_timeout, 0); - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); return 0; } diff --git a/arch/mips/sgi-ip32/ip32-reset.c b/arch/mips/sgi-ip32/ip32-reset.c index 18d1c115cd53..9ee1302c9d13 100644 --- a/arch/mips/sgi-ip32/ip32-reset.c +++ b/arch/mips/sgi-ip32/ip32-reset.c @@ -15,7 +15,6 @@ #include <linux/panic_notifier.h> #include <linux/sched.h> #include <linux/sched/signal.h> -#include <linux/notifier.h> #include <linux/delay.h> #include <linux/rtc/ds1685.h> #include <linux/interrupt.h> @@ -145,7 +144,7 @@ static __init int ip32_reboot_setup(void) pm_power_off = ip32_machine_halt; timer_setup(&blink_timer, blink_timeout, 0); - atomic_notifier_chain_register(&panic_notifier_list, &panic_block); + atomic_notifier_chain_register(&panic_hypervisor_list, &panic_block); return 0; } diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index 52f96b209a96..1468c3937bf4 100644 --- a/arch/powerpc/kernel/setup-common.c +++ b/arch/powerpc/kernel/setup-common.c @@ -753,7 +753,7 @@ static struct notifier_block ppc_panic_block = { void __init setup_panic(void) { /* Hard-disables IRQs + deal with FW-assisted dump (fadump) */ - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &ppc_fadump_block); if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && kaslr_offset() > 0) diff --git a/arch/sparc/kernel/sstate.c b/arch/sparc/kernel/sstate.c index 3bcc4ddc6911..82b7b68e0bdc 100644 --- a/arch/sparc/kernel/sstate.c +++ b/arch/sparc/kernel/sstate.c @@ -5,7 +5,6 @@ */ #include <linux/kernel.h> -#include <linux/notifier.h> #include <linux/panic_notifier.h> #include <linux/reboot.h> #include <linux/init.h> @@ -106,7 +105,7 @@ static int __init sstate_init(void) do_set_sstate(HV_SOFT_STATE_TRANSITION, booting_msg); - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &sstate_panic_block); register_reboot_notifier(&sstate_reboot_notifier); diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c index b01ed02e4a87..ff0bebe2f444 100644 --- a/drivers/firmware/google/gsmi.c +++ b/drivers/firmware/google/gsmi.c @@ -1034,7 +1034,7 @@ static __init int gsmi_init(void) register_reboot_notifier(&gsmi_reboot_notifier); register_die_notifier(&gsmi_die_notifier); - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &gsmi_panic_notifier); printk(KERN_INFO "gsmi version " DRIVER_VERSION " loaded\n"); @@ -1061,7 +1061,7 @@ static void __exit gsmi_exit(void) { unregister_reboot_notifier(&gsmi_reboot_notifier); unregister_die_notifier(&gsmi_die_notifier); - atomic_notifier_chain_unregister(&panic_notifier_list, + atomic_notifier_chain_unregister(&panic_hypervisor_list, &gsmi_panic_notifier); #ifdef CONFIG_EFI efivars_unregister(&efivars); diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index f37f12d48001..901b97034308 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -1614,7 +1614,7 @@ static int vmbus_bus_init(void) hv_kmsg_dump_register(); register_die_notifier(&hyperv_die_report_block); - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &hyperv_panic_report_block); } @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void) if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) { kmsg_dump_unregister(&hv_kmsg_dumper); unregister_die_notifier(&hyperv_die_report_block); - atomic_notifier_chain_unregister(&panic_notifier_list, + atomic_notifier_chain_unregister(&panic_hypervisor_list, &hyperv_panic_report_block); } diff --git a/drivers/leds/trigger/ledtrig-activity.c b/drivers/leds/trigger/ledtrig-activity.c index 30bc9df03636..bbbcf3bc17e3 100644 --- a/drivers/leds/trigger/ledtrig-activity.c +++ b/drivers/leds/trigger/ledtrig-activity.c @@ -247,7 +247,7 @@ static int __init activity_init(void) int rc = led_trigger_register(&activity_led_trigger); if (!rc) { - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &activity_panic_nb); register_reboot_notifier(&activity_reboot_nb); } @@ -257,7 +257,7 @@ static int __init activity_init(void) static void __exit activity_exit(void) { unregister_reboot_notifier(&activity_reboot_nb); - atomic_notifier_chain_unregister(&panic_notifier_list, + atomic_notifier_chain_unregister(&panic_hypervisor_list, &activity_panic_nb); led_trigger_unregister(&activity_led_trigger); } diff --git a/drivers/leds/trigger/ledtrig-heartbeat.c b/drivers/leds/trigger/ledtrig-heartbeat.c index 7fe0a05574d2..a1ed25e83c8f 100644 --- a/drivers/leds/trigger/ledtrig-heartbeat.c +++ b/drivers/leds/trigger/ledtrig-heartbeat.c @@ -190,7 +190,7 @@ static int __init heartbeat_trig_init(void) int rc = led_trigger_register(&heartbeat_led_trigger); if (!rc) { - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &heartbeat_panic_nb); register_reboot_notifier(&heartbeat_reboot_nb); } @@ -200,7 +200,7 @@ static int __init heartbeat_trig_init(void) static void __exit heartbeat_trig_exit(void) { unregister_reboot_notifier(&heartbeat_reboot_nb); - atomic_notifier_chain_unregister(&panic_notifier_list, + atomic_notifier_chain_unregister(&panic_hypervisor_list, &heartbeat_panic_nb); led_trigger_unregister(&heartbeat_led_trigger); } diff --git a/drivers/misc/bcm-vk/bcm_vk_dev.c b/drivers/misc/bcm-vk/bcm_vk_dev.c index a16b99bdaa13..d9d5199cdb2b 100644 --- a/drivers/misc/bcm-vk/bcm_vk_dev.c +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c @@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const struct pci_device_id *ent) /* register for panic notifier */ vk->panic_nb.notifier_call = bcm_vk_on_panic; - err = atomic_notifier_chain_register(&panic_notifier_list, + err = atomic_notifier_chain_register(&panic_hypervisor_list, &vk->panic_nb); if (err) { dev_err(dev, "Fail to register panic notifier\n"); @@ -1486,7 +1486,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const struct pci_device_id *ent) bcm_vk_tty_exit(vk); err_unregister_panic_notifier: - atomic_notifier_chain_unregister(&panic_notifier_list, + atomic_notifier_chain_unregister(&panic_hypervisor_list, &vk->panic_nb); err_destroy_workqueue: @@ -1559,7 +1559,7 @@ static void bcm_vk_remove(struct pci_dev *pdev) usleep_range(BCM_VK_UCODE_BOOT_US, BCM_VK_UCODE_BOOT_MAX_US); /* unregister panic notifier */ - atomic_notifier_chain_unregister(&panic_notifier_list, + atomic_notifier_chain_unregister(&panic_hypervisor_list, &vk->panic_nb); bcm_vk_msg_remove(vk); diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c index 049a12006348..233a71d89477 100644 --- a/drivers/misc/pvpanic/pvpanic.c +++ b/drivers/misc/pvpanic/pvpanic.c @@ -101,7 +101,7 @@ static int pvpanic_init(void) INIT_LIST_HEAD(&pvpanic_list); spin_lock_init(&pvpanic_lock); - atomic_notifier_chain_register(&panic_notifier_list, &pvpanic_panic_nb); + atomic_notifier_chain_register(&panic_hypervisor_list, &pvpanic_panic_nb); return 0; } @@ -109,7 +109,7 @@ module_init(pvpanic_init); static void pvpanic_exit(void) { - atomic_notifier_chain_unregister(&panic_notifier_list, &pvpanic_panic_nb); + atomic_notifier_chain_unregister(&panic_hypervisor_list, &pvpanic_panic_nb); } module_exit(pvpanic_exit); diff --git a/drivers/power/reset/ltc2952-poweroff.c b/drivers/power/reset/ltc2952-poweroff.c index 65d9528cc989..fb5078ba3a69 100644 --- a/drivers/power/reset/ltc2952-poweroff.c +++ b/drivers/power/reset/ltc2952-poweroff.c @@ -279,7 +279,7 @@ static int ltc2952_poweroff_probe(struct platform_device *pdev) pm_power_off = ltc2952_poweroff_kill; data->panic_notifier.notifier_call = ltc2952_poweroff_notify_panic; - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &data->panic_notifier); dev_info(&pdev->dev, "probe successful\n"); @@ -293,7 +293,7 @@ static int ltc2952_poweroff_remove(struct platform_device *pdev) pm_power_off = NULL; hrtimer_cancel(&data->timer_trigger); hrtimer_cancel(&data->timer_wde); - atomic_notifier_chain_unregister(&panic_notifier_list, + atomic_notifier_chain_unregister(&panic_hypervisor_list, &data->panic_notifier); return 0; } diff --git a/drivers/s390/char/zcore.c b/drivers/s390/char/zcore.c index 516783ba950f..768a8a3a9046 100644 --- a/drivers/s390/char/zcore.c +++ b/drivers/s390/char/zcore.c @@ -246,7 +246,7 @@ static int zcore_reboot_and_on_panic_handler(struct notifier_block *self, if (hsa_available) release_hsa(); - return NOTIFY_OK; + return NOTIFY_DONE; } static struct notifier_block zcore_reboot_notifier = { @@ -322,7 +322,8 @@ static int __init zcore_init(void) NULL, &zcore_hsa_fops); register_reboot_notifier(&zcore_reboot_notifier); - atomic_notifier_chain_register(&panic_notifier_list, &zcore_on_panic_notifier); + atomic_notifier_chain_register(&panic_hypervisor_list, + &zcore_on_panic_notifier); return 0; fail: diff --git a/drivers/soc/bcm/brcmstb/pm/pm-arm.c b/drivers/soc/bcm/brcmstb/pm/pm-arm.c index 870686ae042b..babca66c7862 100644 --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c @@ -814,7 +814,7 @@ static int brcmstb_pm_probe(struct platform_device *pdev) goto out; } - atomic_notifier_chain_register(&panic_notifier_list, + atomic_notifier_chain_register(&panic_hypervisor_list, &brcmstb_pm_panic_nb); pm_power_off = brcmstb_pm_poweroff; diff --git a/include/linux/panic_notifier.h b/include/linux/panic_notifier.h index 07dced83a783..0bb9dc0dea04 100644 --- a/include/linux/panic_notifier.h +++ b/include/linux/panic_notifier.h @@ -6,6 +6,7 @@ #include <linux/types.h> extern struct atomic_notifier_head panic_notifier_list; +extern struct atomic_notifier_head panic_hypervisor_list; extern bool crash_kexec_post_notifiers; diff --git a/kernel/panic.c b/kernel/panic.c index 523bc9ccd0e9..ef76f3f9c44d 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -73,6 +73,9 @@ ATOMIC_NOTIFIER_HEAD(panic_notifier_list); EXPORT_SYMBOL(panic_notifier_list); +ATOMIC_NOTIFIER_HEAD(panic_hypervisor_list); +EXPORT_SYMBOL(panic_hypervisor_list); + static long no_blink(int state) { return 0; @@ -287,6 +290,7 @@ void panic(const char *fmt, ...) * Run any panic handlers, including those that might need to * add information to the kmsg dump output. */ + atomic_notifier_call_chain(&panic_hypervisor_list, PANIC_NOTIFIER, buf); atomic_notifier_call_chain(&panic_notifier_list, PANIC_NOTIFIER, buf); panic_print_sys_info(false);
The goal of this new panic notifier is to allow its users to register callbacks to run very early in the panic path. This aims hypervisor/FW notification mechanisms as well as simple LED functions, and any other simple and safe mechanism that should run early in the panic path; more dangerous callbacks should execute later. For now, the patch is almost a no-op (although it changes a bit the ordering in which some panic notifiers are executed). In a subsequent patch, the panic path will be refactored, then the panic hypervisor notifiers will effectively run very early in the panic path. We also defer documenting it all properly in the subsequent refactor patch. While at it, we removed some useless header inclusions and fixed some notifiers return too (by using the standard NOTIFY_DONE). Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: David Gow <davidgow@google.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Dexuan Cui <decui@microsoft.com> Cc: Doug Berger <opendmb@gmail.com> Cc: Evan Green <evgreen@chromium.org> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Justin Chen <justinpopo6@gmail.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Markus Mayer <mmayer@broadcom.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michael Kelley <mikelley@microsoft.com> Cc: Mihai Carabas <mihai.carabas@oracle.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Scott Branden <scott.branden@broadcom.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Shile Zhang <shile.zhang@linux.alibaba.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Tianyu Lan <Tianyu.Lan@microsoft.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Wang ShaoBo <bobo.shaobowang@huawei.com> Cc: Wei Liu <wei.liu@kernel.org> Cc: zhenwei pi <pizhenwei@bytedance.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> --- arch/mips/sgi-ip22/ip22-reset.c | 2 +- arch/mips/sgi-ip32/ip32-reset.c | 3 +-- arch/powerpc/kernel/setup-common.c | 2 +- arch/sparc/kernel/sstate.c | 3 +-- drivers/firmware/google/gsmi.c | 4 ++-- drivers/hv/vmbus_drv.c | 4 ++-- drivers/leds/trigger/ledtrig-activity.c | 4 ++-- drivers/leds/trigger/ledtrig-heartbeat.c | 4 ++-- drivers/misc/bcm-vk/bcm_vk_dev.c | 6 +++--- drivers/misc/pvpanic/pvpanic.c | 4 ++-- drivers/power/reset/ltc2952-poweroff.c | 4 ++-- drivers/s390/char/zcore.c | 5 +++-- drivers/soc/bcm/brcmstb/pm/pm-arm.c | 2 +- include/linux/panic_notifier.h | 1 + kernel/panic.c | 4 ++++ 15 files changed, 28 insertions(+), 24 deletions(-)