From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9640CC4332F for ; Mon, 16 May 2022 15:07:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244948AbiEPPHb (ORCPT ); Mon, 16 May 2022 11:07:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238196AbiEPPHa (ORCPT ); Mon, 16 May 2022 11:07:30 -0400 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E1863B3DA; Mon, 16 May 2022 08:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=x8rylV2fo2RhFyw7lXZ7iRi1TUSl/qSAgQ1QFQa6Swk=; b=feXctn9xVfAtMOxpqtYyQ3CA85 BjdcLwwe8TiMsRw2fUykvtPuvzY6hmKnTuAYE+A0XsmmVYSLQ/kcthiUMBKg0mNjJ1yc4l+lLSsmf USmCbBkmQnOZm2iGOSrx6Rl0cCpZ73ILK767ZxXmwm6a3QHv/+OS7mfra0PYCo9fNU1O9VQyfm4pw 6HrCZSPKvKswSfp/Eu6sagLk3Urn9HpvONKk/wFmV32LKFF9WaILoOgpFS5qfU8S7XCa8c/aUXIoQ 86eaCmPOCcjnQf8OfgMGzWfOoSFt/jwGca1nP55u94yjF/tPVCKn3Ik3vagLqYanseWDcV4ZXGkRO T9pShFkw==; Received: from [177.183.162.244] (helo=[192.168.0.5]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1nqcJI-006nIW-Cg; Mon, 16 May 2022 17:07:00 +0200 Message-ID: Date: Mon, 16 May 2022 12:06:17 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list Content-Language: en-US To: Petr Mladek , David Gow , Evan Green , Julius Werner , Scott Branden , bcm-kernel-feedback-list@broadcom.com, Sebastian Reichel , linux-pm@vger.kernel.org, Florian Fainelli Cc: akpm@linux-foundation.org, bhe@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-leds@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-s390@vger.kernel.org, linux-tegra@vger.kernel.org, linux-um@lists.infradead.org, linux-xtensa@linux-xtensa.org, netdev@vger.kernel.org, openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org, sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org, x86@kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net, halves@canonical.com, fabiomirmar@gmail.com, alejandro.j.jimenez@oracle.com, andriy.shevchenko@linux.intel.com, arnd@arndb.de, bp@alien8.de, corbet@lwn.net, d.hatayama@jp.fujitsu.com, dave.hansen@linux.intel.com, dyoung@redhat.com, feng.tang@intel.com, gregkh@linuxfoundation.org, mikelley@microsoft.com, hidehiro.kawai.ez@hitachi.com, jgross@suse.com, john.ogness@linutronix.de, keescook@chromium.org, luto@kernel.org, mhiramat@kernel.org, mingo@redhat.com, paulmck@kernel.org, peterz@infradead.org, rostedt@goodmis.org, senozhatsky@chromium.org, stern@rowland.harvard.edu, tglx@linutronix.de, vgoyal@redhat.com, vkuznets@redhat.com, will@kernel.org, Alexander Gordeev , Andrea Parri , Ard Biesheuvel , Benjamin Herrenschmidt , Brian Norris , Christian Borntraeger , Christophe JAILLET , "David S. Miller" , Dexuan Cui , Doug Berger , Haiyang Zhang , Hari Bathini , Heiko Carstens , Justin Chen , "K. Y. Srinivasan" , Lee Jones , Markus Mayer , Michael Ellerman , Mihai Carabas , Nicholas Piggin , Paul Mackerras , Pavel Machek , Shile Zhang , Stephen Hemminger , Sven Schnelle , Thomas Bogendoerfer , Tianyu Lan , Vasily Gorbik , Wang ShaoBo , Wei Liu , zhenwei pi References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-20-gpiccoli@igalia.com> From: "Guilherme G. Piccoli" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 90914C433EF for ; Mon, 16 May 2022 21:44:08 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4L2CSR0t04z3cBK for ; Tue, 17 May 2022 07:44:07 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=igalia.com header.i=@igalia.com header.a=rsa-sha256 header.s=20170329 header.b=feXctn9x; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=igalia.com (client-ip=178.60.130.6; helo=fanzine2.igalia.com; envelope-from=gpiccoli@igalia.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=igalia.com header.i=@igalia.com header.a=rsa-sha256 header.s=20170329 header.b=feXctn9x; dkim-atps=neutral Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4L22g03ZQGz3bhR for ; Tue, 17 May 2022 01:07:39 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=x8rylV2fo2RhFyw7lXZ7iRi1TUSl/qSAgQ1QFQa6Swk=; b=feXctn9xVfAtMOxpqtYyQ3CA85 BjdcLwwe8TiMsRw2fUykvtPuvzY6hmKnTuAYE+A0XsmmVYSLQ/kcthiUMBKg0mNjJ1yc4l+lLSsmf USmCbBkmQnOZm2iGOSrx6Rl0cCpZ73ILK767ZxXmwm6a3QHv/+OS7mfra0PYCo9fNU1O9VQyfm4pw 6HrCZSPKvKswSfp/Eu6sagLk3Urn9HpvONKk/wFmV32LKFF9WaILoOgpFS5qfU8S7XCa8c/aUXIoQ 86eaCmPOCcjnQf8OfgMGzWfOoSFt/jwGca1nP55u94yjF/tPVCKn3Ik3vagLqYanseWDcV4ZXGkRO T9pShFkw==; Received: from [177.183.162.244] (helo=[192.168.0.5]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1nqcJI-006nIW-Cg; Mon, 16 May 2022 17:07:00 +0200 Message-ID: Date: Mon, 16 May 2022 12:06:17 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list Content-Language: en-US To: Petr Mladek , David Gow , Evan Green , Julius Werner , Scott Branden , bcm-kernel-feedback-list@broadcom.com, Sebastian Reichel , linux-pm@vger.kernel.org, Florian Fainelli References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-20-gpiccoli@igalia.com> From: "Guilherme G. Piccoli" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 May 2022 07:40:39 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hyperv@vger.kernel.org, halves@canonical.com, Markus Mayer , gregkh@linuxfoundation.org, peterz@infradead.org, alejandro.j.jimenez@oracle.com, linux-remoteproc@vger.kernel.org, feng.tang@intel.com, Vasily Gorbik , linux-mips@vger.kernel.org, hidehiro.kawai.ez@hitachi.com, Paul Mackerras , Justin Chen , Pavel Machek , sparclinux@vger.kernel.org, Alexander Gordeev , "K. Y. Srinivasan" , will@kernel.org, tglx@linutronix.de, linux-leds@vger.kernel.org, linux-s390@vger.kernel.org, Wei Liu , Doug Berger , mikelley@microsoft.com, john.ogness@linutronix.de, bhe@redhat.com, corbet@lwn.net, paulmck@kernel.org, fabiomirmar@gmail.com, x86@kernel.org, Dexuan Cui , zhenwei pi , Ard Biesheuvel , mingo@redhat.com, stern@rowland.harvard.edu, Hari Bathini , xen-devel@lists.xenproject.org, Christian Borntraeger , dyoung@redhat.com, Heiko Carstens , vgoyal@redhat.com, Sven Schnelle , Andrea Parri , linux-xtensa@linux-xtensa.org, dave.hansen@linux.intel.com, Tianyu Lan , keescook@chromium.org, arnd@arndb.de, Mihai Carabas , Haiyang Zhang , Shile Zhang , linux-um@lists.infradead.org, rostedt@goodmis.org, rcu@vger.kernel.org, Wang ShaoBo , Thomas Bogendoerfer , bp@alien8.de, Nicholas Piggin , luto@kernel.org, linux-tegra@vger.kernel.org, Stephen Hemminger , openipmi-developer@lists.sourceforge.net, andriy.shevchenko@linux.intel.com, vkuznets@redhat.com, linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org, jgross@suse.com, Lee Jones , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, kernel@gpiccoli.net, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, senozhatsky@chromium.org, d.hatayama@jp.fujitsu.com, mhiramat@kernel.org, kernel-dev@igalia.com, linux-alpha@vger.kernel.org, Christophe JAILLET , akpm@linux-foundation.org, Brian Norris , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guilherme G. Piccoli Date: Mon, 16 May 2022 12:06:17 -0300 Subject: [PATCH 19/30] panic: Add the panic hypervisor notifier list In-Reply-To: References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-20-gpiccoli@igalia.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kexec@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: Date: Mon, 16 May 2022 12:06:17 -0300 MIME-Version: 1.0 Subject: Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list Content-Language: en-US References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-20-gpiccoli@igalia.com> From: "Guilherme G. Piccoli" In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Petr Mladek , David Gow , Evan Green , Julius Werner , Scott Branden , bcm-kernel-feedback-list@broadcom.com, Sebastian Reichel , linux-pm@vger.kernel.org, Florian Fainelli Cc: akpm@linux-foundation.org, bhe@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-leds@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-s390@vger.kernel.org, linux-tegra@vger.kernel.org, linux-um@lists.infradead.org, linux-xtensa@linux-xtensa.org, netdev@vger.kernel.org, openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org, sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org, x86@kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net, halves@canonical.com, fabiomirmar@gmail.com, alejandro.j.jimenez@oracle.com, andriy.shevchenko@linux.intel.com, arnd@arndb.de, bp@alien8.de, corbet@lwn.net, d.hatayama@jp.fujitsu.com, dave.hansen@linux.intel.com, dyoung@redhat.com, feng.tang@intel.com, gregkh@linuxfoundation.org, mikelley@microsoft.com, hidehiro.kawai.ez@hitachi.com, jgross@suse.com, john.ogness@linutronix.de, keescook@chromium.org, luto@kernel.org, mhiramat@kernel.org, mingo@redhat.com, paulmck@kernel.org, peterz@infradead.org, rostedt@goodmis.org, senozhatsky@chromium.org, stern@rowland.harvard.edu, tglx@linutronix.de, vgoyal@redhat.com, vkuznets@redhat.com, will@kernel.org, Alexander Gordeev , Andrea Parri , Ard Biesheuvel , Benjamin Herrenschmidt , Brian Norris , Christian Borntraeger , Christophe JAILLET , "David S. Miller" , Dexuan Cui , Doug Berger , Haiyang Zhang , Hari Bathini , Heiko Carstens , Justin Chen , "K. Y. Srinivasan" , Lee Jones , Markus Mayer , Michael Ellerman , Mihai Carabas , Nicholas Piggin , Paul Mackerras , Pavel Machek , Shile Zhang , Stephen Hemminger , Sven Schnelle , Thomas Bogendoerfer , Tianyu Lan , Vasily Gorbik , Wang ShaoBo , Wei Liu , zhenwei pi 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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Guilherme G. Piccoli" Subject: Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list Date: Mon, 16 May 2022 12:06:17 -0300 Message-ID: References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-20-gpiccoli@igalia.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=x8rylV2fo2RhFyw7lXZ7iRi1TUSl/qSAgQ1QFQa6Swk=; b=feXctn9xVfAtMOxpqtYyQ3CA85 BjdcLwwe8TiMsRw2fUykvtPuvzY6hmKnTuAYE+A0XsmmVYSLQ/kcthiUMBKg0mNjJ1yc4l+lLSsmf USmCbBkmQnOZm2iGOSrx6Rl0cCpZ73ILK767ZxXmwm6a3QHv/+OS7mfra0PYCo9fNU1O9VQyfm4pw 6HrCZSPKvKswSfp/Eu6sagLk3Urn9HpvONKk/wFmV32LKFF9WaILoOgpFS5qfU8S7XCa8c/aUXIoQ 86eaCmPOCcjnQf8OfgMGzWfOoSFt/jwGca1nP55u94yjF/tPVCKn3Ik3vagLqYanseWDcV4ZXGkRO T9pShFk Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Petr Mladek , David Gow , Evan Green , Julius Werner , Scott Branden , bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org, Sebastian Reichel , linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Florian Fainelli Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-alpha-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-hyperv-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mips-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-parisc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-remoteproc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, rcu-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, kernel-dev-wEGTBA9jqPzQT0dZR+AlfA@public.gmane.org, kernel-WeLdAqEWwDvk1uMJSBkQmQ@public.gmane.org, halves-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org, fabiomirmar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, alejandro.j.jimenez-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, andriy.shevche 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