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