All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: akpm@linux-foundation.org, bhe@redhat.com, pmladek@suse.com,
	kexec@lists.infradead.org
Cc: linux-kernel@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	coresight@lists.linaro.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-pm@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, gpiccoli@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,
	Andrea Parri <parri.andrea@gmail.com>,
	Dexuan Cui <decui@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>
Subject: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers
Date: Wed, 27 Apr 2022 19:49:10 -0300	[thread overview]
Message-ID: <20220427224924.592546-17-gpiccoli@igalia.com> (raw)
In-Reply-To: <20220427224924.592546-1-gpiccoli@igalia.com>

Currently Hyper-V guests are among the most relevant users of the panic
infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
both in cleaning-up procedures (closing a hypervisor <-> guest connection,
disabling a paravirtualized timer) as well as to data collection (sending
panic information to the hypervisor) and framebuffer management.

The thing is: some notifiers are related to others, ordering matters, some
functionalities are duplicated and there are lots of conditionals behind
sending panic information to the hypervisor. This patch, as part of an
effort to clean-up the panic notifiers mechanism and better document
things, address some of the issues/complexities of Hyper-V panic handling
through the following changes:

(a) We have die and panic notifiers on vmbus_drv.c and both have goals of
sending panic information to the hypervisor, though the panic notifier is
also responsible for a cleaning-up procedure.

This commit clears the code by splitting the panic notifier in two, one
for closing the vmbus connection whereas the other is only for sending
panic info to hypervisor. With that, it was possible to merge the die and
panic notifiers in a single/well-documented function, and clear some
conditional complexities on sending such information to the hypervisor.

(b) The new panic notifier created after (a) is only doing a single thing:
cleaning the vmbus connection. This procedure might cause a delay (due to
hypervisor I/O completion), so we postpone that to run late. But more
relevant: this *same* vmbus unloading happens in the crash_shutdown()
handler, so if kdump is set, we can safely skip this panic notifier and
defer such clean-up to the kexec crash handler.

(c) There is also a Hyper-V framebuffer panic notifier, which relies in
doing a vmbus operation that demands a valid connection. So, we must
order this notifier with the panic notifier from vmbus_drv.c, in order to
guarantee that the framebuffer code executes before the vmbus connection
is unloaded.

Also, this commit removes a useless header.

Although there is code rework and re-ordering, we expect that this change
has no functional regressions but instead optimize the path and increase
panic reliability on Hyper-V. This was tested on Hyper-V with success.

Fixes: 792f232d57ff ("Drivers: hv: vmbus: Fix potential crash on module unload")
Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Tianyu Lan <Tianyu.Lan@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Tested-by: Fabio A M Martins <fabiomirmar@gmail.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
---

Special thanks to Michael Kelley for the good information about the Hyper-V
panic path in email threads some months ago, and to Fabio for the testing
performed.

Michael and all Microsoft folks: a careful analysis to double-check our changes
and assumptions here is really appreciated, this code is complex and intricate,
it is possible some corner case might have been overlooked.

Thanks in advance!

 drivers/hv/vmbus_drv.c          | 109 ++++++++++++++++++++------------
 drivers/video/fbdev/hyperv_fb.c |   8 +++
 2 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 14de17087864..f37f12d48001 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -24,11 +24,11 @@
 #include <linux/sched/task_stack.h>
 
 #include <linux/delay.h>
-#include <linux/notifier.h>
 #include <linux/panic_notifier.h>
 #include <linux/ptrace.h>
 #include <linux/screen_info.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/efi.h>
 #include <linux/random.h>
 #include <linux/kernel.h>
@@ -68,51 +68,75 @@ static int hyperv_report_reg(void)
 	return !sysctl_record_panic_msg || !hv_panic_page;
 }
 
-static int hyperv_panic_event(struct notifier_block *nb, unsigned long val,
+/*
+ * The panic notifier below is responsible solely for unloading the
+ * vmbus connection, which is necessary in a panic event. But notice
+ * that this same unloading procedure is executed in the Hyper-V
+ * crash_shutdown() handler [see hv_crash_handler()], which basically
+ * means that we can postpone its execution if we have kdump set,
+ * since it will run the crash_shutdown() handler anyway. Even more
+ * intrincated is the relation of this notifier with Hyper-V framebuffer
+ * panic notifier - we need vmbus connection alive there in order to
+ * succeed, so we need to order both with each other [for reference see
+ * hvfb_on_panic()] - this is done using notifiers' priorities.
+ */
+static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
 			      void *args)
+{
+	if (!kexec_crash_loaded())
+		vmbus_initiate_unload(true);
+
+	return NOTIFY_DONE;
+}
+static struct notifier_block hyperv_panic_vmbus_unload_block = {
+	.notifier_call	= hv_panic_vmbus_unload,
+	.priority	= INT_MIN + 1, /* almost the latest one to execute */
+};
+
+/*
+ * The following callback works both as die and panic notifier; its
+ * goal is to provide panic information to the hypervisor unless the
+ * kmsg dumper is gonna be used [see hv_kmsg_dump()], which provides
+ * more information but is not always available.
+ *
+ * Notice that both the panic/die report notifiers are registered only
+ * if we have the capability HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE set.
+ */
+static int hv_die_panic_notify_crash(struct notifier_block *nb,
+				     unsigned long val, void *args)
 {
 	struct pt_regs *regs;
+	bool is_die;
 
-	vmbus_initiate_unload(true);
-
-	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
-	 */
-	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE
-	    && hyperv_report_reg()) {
+	/* Don't notify Hyper-V unless we have a die oops event or panic. */
+	switch (val) {
+	case DIE_OOPS:
+		is_die = true;
+		regs = ((struct die_args *)args)->regs;
+		break;
+	case PANIC_NOTIFIER:
+		is_die = false;
 		regs = current_pt_regs();
-		hyperv_report_panic(regs, val, false);
-	}
-	return NOTIFY_DONE;
-}
-
-static int hyperv_die_event(struct notifier_block *nb, unsigned long val,
-			    void *args)
-{
-	struct die_args *die = args;
-	struct pt_regs *regs = die->regs;
-
-	/* Don't notify Hyper-V if the die event is other than oops */
-	if (val != DIE_OOPS)
+		break;
+	default:
 		return NOTIFY_DONE;
+	}
 
 	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
+	 * Hyper-V should be notified only once about a panic/die. If we will
+	 * be calling hv_kmsg_dump() later with kmsg data, don't do the
+	 * notification here.
 	 */
 	if (hyperv_report_reg())
-		hyperv_report_panic(regs, val, true);
+		hyperv_report_panic(regs, val, is_die);
+
 	return NOTIFY_DONE;
 }
-
-static struct notifier_block hyperv_die_block = {
-	.notifier_call = hyperv_die_event,
+static struct notifier_block hyperv_die_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
-static struct notifier_block hyperv_panic_block = {
-	.notifier_call = hyperv_panic_event,
+static struct notifier_block hyperv_panic_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
 
 static const char *fb_mmio_name = "fb_range";
@@ -1589,16 +1613,17 @@ static int vmbus_bus_init(void)
 		if (hyperv_crash_ctl & HV_CRASH_CTL_CRASH_NOTIFY_MSG)
 			hv_kmsg_dump_register();
 
-		register_die_notifier(&hyperv_die_block);
+		register_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_register(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * Always register the panic notifier because we need to unload
-	 * the VMbus channel connection to prevent any VMbus
-	 * activity after the VM panics.
+	 * Always register the vmbus unload panic notifier because we
+	 * need to shut the VMbus channel connection on panic.
 	 */
 	atomic_notifier_chain_register(&panic_notifier_list,
-			       &hyperv_panic_block);
+			       &hyperv_panic_vmbus_unload_block);
 
 	vmbus_request_offers();
 
@@ -2817,15 +2842,17 @@ 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_block);
+		unregister_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_unregister(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * The panic notifier is always registered, hence we should
+	 * The vmbus panic notifier is always registered, hence we should
 	 * also unconditionally unregister it here as well.
 	 */
 	atomic_notifier_chain_unregister(&panic_notifier_list,
-					 &hyperv_panic_block);
+					&hyperv_panic_vmbus_unload_block);
 
 	free_page((unsigned long)hv_panic_page);
 	unregister_sysctl_table(hv_ctl_table_hdr);
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index c8e0ea27caf1..f3494b868a64 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1244,7 +1244,15 @@ static int hvfb_probe(struct hv_device *hdev,
 	par->fb_ready = true;
 
 	par->synchronous_fb = false;
+
+	/*
+	 * We need to be sure this panic notifier runs _before_ the
+	 * vmbus disconnect, so order it by priority. It must execute
+	 * before the function hv_panic_vmbus_unload() [drivers/hv/vmbus_drv.c],
+	 * which is almost at the end of list, with priority = INT_MIN + 1.
+	 */
 	par->hvfb_panic_nb.notifier_call = hvfb_on_panic;
+	par->hvfb_panic_nb.priority = INT_MIN + 10,
 	atomic_notifier_chain_register(&panic_notifier_list,
 				       &par->hvfb_panic_nb);
 
-- 
2.36.0


WARNING: multiple messages have this Message-ID (diff)
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: akpm@linux-foundation.org, bhe@redhat.com, pmladek@suse.com,
	kexec@lists.infradead.org
Cc: linux-hyperv@vger.kernel.org, halves@canonical.com,
	gregkh@linuxfoundation.org, peterz@infradead.org,
	alejandro.j.jimenez@oracle.com, linux-remoteproc@vger.kernel.org,
	feng.tang@intel.com, linux-mips@vger.kernel.org,
	hidehiro.kawai.ez@hitachi.com, sparclinux@vger.kernel.org,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	will@kernel.org, tglx@linutronix.de, linux-leds@vger.kernel.org,
	linux-s390@vger.kernel.org, Wei Liu <wei.liu@kernel.org>,
	mikelley@microsoft.com, john.ogness@linutronix.de,
	corbet@lwn.net, paulmck@kernel.org, fabiomirmar@gmail.com,
	x86@kernel.org, Dexuan Cui <decui@microsoft.com>,
	mingo@redhat.com, bcm-kernel-feedback-list@broadcom.com,
	xen-devel@lists.xenproject.org, dyoung@redhat.com,
	Haiyang Zhang <haiyangz@microsoft.com>,
	vgoyal@redhat.com, Andrea Parri <parri.andrea@gmail.com>,
	linux-xtensa@linux-xtensa.org, dave.hansen@linux.intel.com,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	keescook@chromium.org, arnd@arndb.de, linux-pm@vger.kernel.org,
	coresight@lists.linaro.org, linux-um@lists.infradead.org,
	rostedt@goodmis.org, rcu@vger.kernel.org, bp@alien8.de,
	luto@kernel.org, linux-tegra@vger.kernel.org,
	Stephen Hemminger <sthemmin@microsoft.com>,
	openipmi-developer@lists.sourceforge.net,
	andriy.shevchenko@linux.intel.com, senozhatsky@chromium.org,
	linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org,
	jgross@suse.com, linux-parisc@vger.kernel.org,
	netdev@vger.kernel.org, kernel@gpiccoli.net,
	linux-kernel@vger.kernel.org, stern@rowland.harvard.edu,
	gpiccoli@igalia.com, d.hatayama@jp.fujitsu.com,
	mhiramat@kernel.org, kernel-dev@igalia.com,
	linux-alpha@vger.kernel.org, vkuznets@redhat.com,
	linuxppc-dev@lists.ozlabs.org
Subject: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers
Date: Wed, 27 Apr 2022 19:49:10 -0300	[thread overview]
Message-ID: <20220427224924.592546-17-gpiccoli@igalia.com> (raw)
In-Reply-To: <20220427224924.592546-1-gpiccoli@igalia.com>

Currently Hyper-V guests are among the most relevant users of the panic
infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
both in cleaning-up procedures (closing a hypervisor <-> guest connection,
disabling a paravirtualized timer) as well as to data collection (sending
panic information to the hypervisor) and framebuffer management.

The thing is: some notifiers are related to others, ordering matters, some
functionalities are duplicated and there are lots of conditionals behind
sending panic information to the hypervisor. This patch, as part of an
effort to clean-up the panic notifiers mechanism and better document
things, address some of the issues/complexities of Hyper-V panic handling
through the following changes:

(a) We have die and panic notifiers on vmbus_drv.c and both have goals of
sending panic information to the hypervisor, though the panic notifier is
also responsible for a cleaning-up procedure.

This commit clears the code by splitting the panic notifier in two, one
for closing the vmbus connection whereas the other is only for sending
panic info to hypervisor. With that, it was possible to merge the die and
panic notifiers in a single/well-documented function, and clear some
conditional complexities on sending such information to the hypervisor.

(b) The new panic notifier created after (a) is only doing a single thing:
cleaning the vmbus connection. This procedure might cause a delay (due to
hypervisor I/O completion), so we postpone that to run late. But more
relevant: this *same* vmbus unloading happens in the crash_shutdown()
handler, so if kdump is set, we can safely skip this panic notifier and
defer such clean-up to the kexec crash handler.

(c) There is also a Hyper-V framebuffer panic notifier, which relies in
doing a vmbus operation that demands a valid connection. So, we must
order this notifier with the panic notifier from vmbus_drv.c, in order to
guarantee that the framebuffer code executes before the vmbus connection
is unloaded.

Also, this commit removes a useless header.

Although there is code rework and re-ordering, we expect that this change
has no functional regressions but instead optimize the path and increase
panic reliability on Hyper-V. This was tested on Hyper-V with success.

Fixes: 792f232d57ff ("Drivers: hv: vmbus: Fix potential crash on module unload")
Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Tianyu Lan <Tianyu.Lan@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Tested-by: Fabio A M Martins <fabiomirmar@gmail.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
---

Special thanks to Michael Kelley for the good information about the Hyper-V
panic path in email threads some months ago, and to Fabio for the testing
performed.

Michael and all Microsoft folks: a careful analysis to double-check our changes
and assumptions here is really appreciated, this code is complex and intricate,
it is possible some corner case might have been overlooked.

Thanks in advance!

 drivers/hv/vmbus_drv.c          | 109 ++++++++++++++++++++------------
 drivers/video/fbdev/hyperv_fb.c |   8 +++
 2 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 14de17087864..f37f12d48001 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -24,11 +24,11 @@
 #include <linux/sched/task_stack.h>
 
 #include <linux/delay.h>
-#include <linux/notifier.h>
 #include <linux/panic_notifier.h>
 #include <linux/ptrace.h>
 #include <linux/screen_info.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/efi.h>
 #include <linux/random.h>
 #include <linux/kernel.h>
@@ -68,51 +68,75 @@ static int hyperv_report_reg(void)
 	return !sysctl_record_panic_msg || !hv_panic_page;
 }
 
-static int hyperv_panic_event(struct notifier_block *nb, unsigned long val,
+/*
+ * The panic notifier below is responsible solely for unloading the
+ * vmbus connection, which is necessary in a panic event. But notice
+ * that this same unloading procedure is executed in the Hyper-V
+ * crash_shutdown() handler [see hv_crash_handler()], which basically
+ * means that we can postpone its execution if we have kdump set,
+ * since it will run the crash_shutdown() handler anyway. Even more
+ * intrincated is the relation of this notifier with Hyper-V framebuffer
+ * panic notifier - we need vmbus connection alive there in order to
+ * succeed, so we need to order both with each other [for reference see
+ * hvfb_on_panic()] - this is done using notifiers' priorities.
+ */
+static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
 			      void *args)
+{
+	if (!kexec_crash_loaded())
+		vmbus_initiate_unload(true);
+
+	return NOTIFY_DONE;
+}
+static struct notifier_block hyperv_panic_vmbus_unload_block = {
+	.notifier_call	= hv_panic_vmbus_unload,
+	.priority	= INT_MIN + 1, /* almost the latest one to execute */
+};
+
+/*
+ * The following callback works both as die and panic notifier; its
+ * goal is to provide panic information to the hypervisor unless the
+ * kmsg dumper is gonna be used [see hv_kmsg_dump()], which provides
+ * more information but is not always available.
+ *
+ * Notice that both the panic/die report notifiers are registered only
+ * if we have the capability HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE set.
+ */
+static int hv_die_panic_notify_crash(struct notifier_block *nb,
+				     unsigned long val, void *args)
 {
 	struct pt_regs *regs;
+	bool is_die;
 
-	vmbus_initiate_unload(true);
-
-	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
-	 */
-	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE
-	    && hyperv_report_reg()) {
+	/* Don't notify Hyper-V unless we have a die oops event or panic. */
+	switch (val) {
+	case DIE_OOPS:
+		is_die = true;
+		regs = ((struct die_args *)args)->regs;
+		break;
+	case PANIC_NOTIFIER:
+		is_die = false;
 		regs = current_pt_regs();
-		hyperv_report_panic(regs, val, false);
-	}
-	return NOTIFY_DONE;
-}
-
-static int hyperv_die_event(struct notifier_block *nb, unsigned long val,
-			    void *args)
-{
-	struct die_args *die = args;
-	struct pt_regs *regs = die->regs;
-
-	/* Don't notify Hyper-V if the die event is other than oops */
-	if (val != DIE_OOPS)
+		break;
+	default:
 		return NOTIFY_DONE;
+	}
 
 	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
+	 * Hyper-V should be notified only once about a panic/die. If we will
+	 * be calling hv_kmsg_dump() later with kmsg data, don't do the
+	 * notification here.
 	 */
 	if (hyperv_report_reg())
-		hyperv_report_panic(regs, val, true);
+		hyperv_report_panic(regs, val, is_die);
+
 	return NOTIFY_DONE;
 }
-
-static struct notifier_block hyperv_die_block = {
-	.notifier_call = hyperv_die_event,
+static struct notifier_block hyperv_die_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
-static struct notifier_block hyperv_panic_block = {
-	.notifier_call = hyperv_panic_event,
+static struct notifier_block hyperv_panic_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
 
 static const char *fb_mmio_name = "fb_range";
@@ -1589,16 +1613,17 @@ static int vmbus_bus_init(void)
 		if (hyperv_crash_ctl & HV_CRASH_CTL_CRASH_NOTIFY_MSG)
 			hv_kmsg_dump_register();
 
-		register_die_notifier(&hyperv_die_block);
+		register_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_register(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * Always register the panic notifier because we need to unload
-	 * the VMbus channel connection to prevent any VMbus
-	 * activity after the VM panics.
+	 * Always register the vmbus unload panic notifier because we
+	 * need to shut the VMbus channel connection on panic.
 	 */
 	atomic_notifier_chain_register(&panic_notifier_list,
-			       &hyperv_panic_block);
+			       &hyperv_panic_vmbus_unload_block);
 
 	vmbus_request_offers();
 
@@ -2817,15 +2842,17 @@ 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_block);
+		unregister_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_unregister(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * The panic notifier is always registered, hence we should
+	 * The vmbus panic notifier is always registered, hence we should
 	 * also unconditionally unregister it here as well.
 	 */
 	atomic_notifier_chain_unregister(&panic_notifier_list,
-					 &hyperv_panic_block);
+					&hyperv_panic_vmbus_unload_block);
 
 	free_page((unsigned long)hv_panic_page);
 	unregister_sysctl_table(hv_ctl_table_hdr);
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index c8e0ea27caf1..f3494b868a64 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1244,7 +1244,15 @@ static int hvfb_probe(struct hv_device *hdev,
 	par->fb_ready = true;
 
 	par->synchronous_fb = false;
+
+	/*
+	 * We need to be sure this panic notifier runs _before_ the
+	 * vmbus disconnect, so order it by priority. It must execute
+	 * before the function hv_panic_vmbus_unload() [drivers/hv/vmbus_drv.c],
+	 * which is almost at the end of list, with priority = INT_MIN + 1.
+	 */
 	par->hvfb_panic_nb.notifier_call = hvfb_on_panic;
+	par->hvfb_panic_nb.priority = INT_MIN + 10,
 	atomic_notifier_chain_register(&panic_notifier_list,
 				       &par->hvfb_panic_nb);
 
-- 
2.36.0


WARNING: multiple messages have this Message-ID (diff)
From: Guilherme G. Piccoli <gpiccoli@igalia.com>
To: kexec@lists.infradead.org
Subject: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers
Date: Wed, 27 Apr 2022 19:49:10 -0300	[thread overview]
Message-ID: <20220427224924.592546-17-gpiccoli@igalia.com> (raw)
In-Reply-To: <20220427224924.592546-1-gpiccoli@igalia.com>

Currently Hyper-V guests are among the most relevant users of the panic
infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
both in cleaning-up procedures (closing a hypervisor <-> guest connection,
disabling a paravirtualized timer) as well as to data collection (sending
panic information to the hypervisor) and framebuffer management.

The thing is: some notifiers are related to others, ordering matters, some
functionalities are duplicated and there are lots of conditionals behind
sending panic information to the hypervisor. This patch, as part of an
effort to clean-up the panic notifiers mechanism and better document
things, address some of the issues/complexities of Hyper-V panic handling
through the following changes:

(a) We have die and panic notifiers on vmbus_drv.c and both have goals of
sending panic information to the hypervisor, though the panic notifier is
also responsible for a cleaning-up procedure.

This commit clears the code by splitting the panic notifier in two, one
for closing the vmbus connection whereas the other is only for sending
panic info to hypervisor. With that, it was possible to merge the die and
panic notifiers in a single/well-documented function, and clear some
conditional complexities on sending such information to the hypervisor.

(b) The new panic notifier created after (a) is only doing a single thing:
cleaning the vmbus connection. This procedure might cause a delay (due to
hypervisor I/O completion), so we postpone that to run late. But more
relevant: this *same* vmbus unloading happens in the crash_shutdown()
handler, so if kdump is set, we can safely skip this panic notifier and
defer such clean-up to the kexec crash handler.

(c) There is also a Hyper-V framebuffer panic notifier, which relies in
doing a vmbus operation that demands a valid connection. So, we must
order this notifier with the panic notifier from vmbus_drv.c, in order to
guarantee that the framebuffer code executes before the vmbus connection
is unloaded.

Also, this commit removes a useless header.

Although there is code rework and re-ordering, we expect that this change
has no functional regressions but instead optimize the path and increase
panic reliability on Hyper-V. This was tested on Hyper-V with success.

Fixes: 792f232d57ff ("Drivers: hv: vmbus: Fix potential crash on module unload")
Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Tianyu Lan <Tianyu.Lan@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Tested-by: Fabio A M Martins <fabiomirmar@gmail.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
---

Special thanks to Michael Kelley for the good information about the Hyper-V
panic path in email threads some months ago, and to Fabio for the testing
performed.

Michael and all Microsoft folks: a careful analysis to double-check our changes
and assumptions here is really appreciated, this code is complex and intricate,
it is possible some corner case might have been overlooked.

Thanks in advance!

 drivers/hv/vmbus_drv.c          | 109 ++++++++++++++++++++------------
 drivers/video/fbdev/hyperv_fb.c |   8 +++
 2 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 14de17087864..f37f12d48001 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -24,11 +24,11 @@
 #include <linux/sched/task_stack.h>
 
 #include <linux/delay.h>
-#include <linux/notifier.h>
 #include <linux/panic_notifier.h>
 #include <linux/ptrace.h>
 #include <linux/screen_info.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/efi.h>
 #include <linux/random.h>
 #include <linux/kernel.h>
@@ -68,51 +68,75 @@ static int hyperv_report_reg(void)
 	return !sysctl_record_panic_msg || !hv_panic_page;
 }
 
-static int hyperv_panic_event(struct notifier_block *nb, unsigned long val,
+/*
+ * The panic notifier below is responsible solely for unloading the
+ * vmbus connection, which is necessary in a panic event. But notice
+ * that this same unloading procedure is executed in the Hyper-V
+ * crash_shutdown() handler [see hv_crash_handler()], which basically
+ * means that we can postpone its execution if we have kdump set,
+ * since it will run the crash_shutdown() handler anyway. Even more
+ * intrincated is the relation of this notifier with Hyper-V framebuffer
+ * panic notifier - we need vmbus connection alive there in order to
+ * succeed, so we need to order both with each other [for reference see
+ * hvfb_on_panic()] - this is done using notifiers' priorities.
+ */
+static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
 			      void *args)
+{
+	if (!kexec_crash_loaded())
+		vmbus_initiate_unload(true);
+
+	return NOTIFY_DONE;
+}
+static struct notifier_block hyperv_panic_vmbus_unload_block = {
+	.notifier_call	= hv_panic_vmbus_unload,
+	.priority	= INT_MIN + 1, /* almost the latest one to execute */
+};
+
+/*
+ * The following callback works both as die and panic notifier; its
+ * goal is to provide panic information to the hypervisor unless the
+ * kmsg dumper is gonna be used [see hv_kmsg_dump()], which provides
+ * more information but is not always available.
+ *
+ * Notice that both the panic/die report notifiers are registered only
+ * if we have the capability HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE set.
+ */
+static int hv_die_panic_notify_crash(struct notifier_block *nb,
+				     unsigned long val, void *args)
 {
 	struct pt_regs *regs;
+	bool is_die;
 
-	vmbus_initiate_unload(true);
-
-	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
-	 */
-	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE
-	    && hyperv_report_reg()) {
+	/* Don't notify Hyper-V unless we have a die oops event or panic. */
+	switch (val) {
+	case DIE_OOPS:
+		is_die = true;
+		regs = ((struct die_args *)args)->regs;
+		break;
+	case PANIC_NOTIFIER:
+		is_die = false;
 		regs = current_pt_regs();
-		hyperv_report_panic(regs, val, false);
-	}
-	return NOTIFY_DONE;
-}
-
-static int hyperv_die_event(struct notifier_block *nb, unsigned long val,
-			    void *args)
-{
-	struct die_args *die = args;
-	struct pt_regs *regs = die->regs;
-
-	/* Don't notify Hyper-V if the die event is other than oops */
-	if (val != DIE_OOPS)
+		break;
+	default:
 		return NOTIFY_DONE;
+	}
 
 	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
+	 * Hyper-V should be notified only once about a panic/die. If we will
+	 * be calling hv_kmsg_dump() later with kmsg data, don't do the
+	 * notification here.
 	 */
 	if (hyperv_report_reg())
-		hyperv_report_panic(regs, val, true);
+		hyperv_report_panic(regs, val, is_die);
+
 	return NOTIFY_DONE;
 }
-
-static struct notifier_block hyperv_die_block = {
-	.notifier_call = hyperv_die_event,
+static struct notifier_block hyperv_die_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
-static struct notifier_block hyperv_panic_block = {
-	.notifier_call = hyperv_panic_event,
+static struct notifier_block hyperv_panic_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
 
 static const char *fb_mmio_name = "fb_range";
@@ -1589,16 +1613,17 @@ static int vmbus_bus_init(void)
 		if (hyperv_crash_ctl & HV_CRASH_CTL_CRASH_NOTIFY_MSG)
 			hv_kmsg_dump_register();
 
-		register_die_notifier(&hyperv_die_block);
+		register_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_register(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * Always register the panic notifier because we need to unload
-	 * the VMbus channel connection to prevent any VMbus
-	 * activity after the VM panics.
+	 * Always register the vmbus unload panic notifier because we
+	 * need to shut the VMbus channel connection on panic.
 	 */
 	atomic_notifier_chain_register(&panic_notifier_list,
-			       &hyperv_panic_block);
+			       &hyperv_panic_vmbus_unload_block);
 
 	vmbus_request_offers();
 
@@ -2817,15 +2842,17 @@ 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_block);
+		unregister_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_unregister(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * The panic notifier is always registered, hence we should
+	 * The vmbus panic notifier is always registered, hence we should
 	 * also unconditionally unregister it here as well.
 	 */
 	atomic_notifier_chain_unregister(&panic_notifier_list,
-					 &hyperv_panic_block);
+					&hyperv_panic_vmbus_unload_block);
 
 	free_page((unsigned long)hv_panic_page);
 	unregister_sysctl_table(hv_ctl_table_hdr);
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index c8e0ea27caf1..f3494b868a64 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1244,7 +1244,15 @@ static int hvfb_probe(struct hv_device *hdev,
 	par->fb_ready = true;
 
 	par->synchronous_fb = false;
+
+	/*
+	 * We need to be sure this panic notifier runs _before_ the
+	 * vmbus disconnect, so order it by priority. It must execute
+	 * before the function hv_panic_vmbus_unload() [drivers/hv/vmbus_drv.c],
+	 * which is almost at the end of list, with priority = INT_MIN + 1.
+	 */
 	par->hvfb_panic_nb.notifier_call = hvfb_on_panic;
+	par->hvfb_panic_nb.priority = INT_MIN + 10,
 	atomic_notifier_chain_register(&panic_notifier_list,
 				       &par->hvfb_panic_nb);
 
-- 
2.36.0



WARNING: multiple messages have this Message-ID (diff)
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: akpm@linux-foundation.org, bhe@redhat.com, pmladek@suse.com,
	kexec@lists.infradead.org
Cc: linux-kernel@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	coresight@lists.linaro.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-pm@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, gpiccoli@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,
	Andrea Parri <parri.andrea@gmail.com>,
	Dexuan Cui <decui@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>
Subject: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers
Date: Wed, 27 Apr 2022 19:49:10 -0300	[thread overview]
Message-ID: <20220427224924.592546-17-gpiccoli@igalia.com> (raw)
In-Reply-To: <20220427224924.592546-1-gpiccoli@igalia.com>

Currently Hyper-V guests are among the most relevant users of the panic
infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
both in cleaning-up procedures (closing a hypervisor <-> guest connection,
disabling a paravirtualized timer) as well as to data collection (sending
panic information to the hypervisor) and framebuffer management.

The thing is: some notifiers are related to others, ordering matters, some
functionalities are duplicated and there are lots of conditionals behind
sending panic information to the hypervisor. This patch, as part of an
effort to clean-up the panic notifiers mechanism and better document
things, address some of the issues/complexities of Hyper-V panic handling
through the following changes:

(a) We have die and panic notifiers on vmbus_drv.c and both have goals of
sending panic information to the hypervisor, though the panic notifier is
also responsible for a cleaning-up procedure.

This commit clears the code by splitting the panic notifier in two, one
for closing the vmbus connection whereas the other is only for sending
panic info to hypervisor. With that, it was possible to merge the die and
panic notifiers in a single/well-documented function, and clear some
conditional complexities on sending such information to the hypervisor.

(b) The new panic notifier created after (a) is only doing a single thing:
cleaning the vmbus connection. This procedure might cause a delay (due to
hypervisor I/O completion), so we postpone that to run late. But more
relevant: this *same* vmbus unloading happens in the crash_shutdown()
handler, so if kdump is set, we can safely skip this panic notifier and
defer such clean-up to the kexec crash handler.

(c) There is also a Hyper-V framebuffer panic notifier, which relies in
doing a vmbus operation that demands a valid connection. So, we must
order this notifier with the panic notifier from vmbus_drv.c, in order to
guarantee that the framebuffer code executes before the vmbus connection
is unloaded.

Also, this commit removes a useless header.

Although there is code rework and re-ordering, we expect that this change
has no functional regressions but instead optimize the path and increase
panic reliability on Hyper-V. This was tested on Hyper-V with success.

Fixes: 792f232d57ff ("Drivers: hv: vmbus: Fix potential crash on module unload")
Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Tianyu Lan <Tianyu.Lan@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Tested-by: Fabio A M Martins <fabiomirmar@gmail.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
---

Special thanks to Michael Kelley for the good information about the Hyper-V
panic path in email threads some months ago, and to Fabio for the testing
performed.

Michael and all Microsoft folks: a careful analysis to double-check our changes
and assumptions here is really appreciated, this code is complex and intricate,
it is possible some corner case might have been overlooked.

Thanks in advance!

 drivers/hv/vmbus_drv.c          | 109 ++++++++++++++++++++------------
 drivers/video/fbdev/hyperv_fb.c |   8 +++
 2 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 14de17087864..f37f12d48001 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -24,11 +24,11 @@
 #include <linux/sched/task_stack.h>
 
 #include <linux/delay.h>
-#include <linux/notifier.h>
 #include <linux/panic_notifier.h>
 #include <linux/ptrace.h>
 #include <linux/screen_info.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/efi.h>
 #include <linux/random.h>
 #include <linux/kernel.h>
@@ -68,51 +68,75 @@ static int hyperv_report_reg(void)
 	return !sysctl_record_panic_msg || !hv_panic_page;
 }
 
-static int hyperv_panic_event(struct notifier_block *nb, unsigned long val,
+/*
+ * The panic notifier below is responsible solely for unloading the
+ * vmbus connection, which is necessary in a panic event. But notice
+ * that this same unloading procedure is executed in the Hyper-V
+ * crash_shutdown() handler [see hv_crash_handler()], which basically
+ * means that we can postpone its execution if we have kdump set,
+ * since it will run the crash_shutdown() handler anyway. Even more
+ * intrincated is the relation of this notifier with Hyper-V framebuffer
+ * panic notifier - we need vmbus connection alive there in order to
+ * succeed, so we need to order both with each other [for reference see
+ * hvfb_on_panic()] - this is done using notifiers' priorities.
+ */
+static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
 			      void *args)
+{
+	if (!kexec_crash_loaded())
+		vmbus_initiate_unload(true);
+
+	return NOTIFY_DONE;
+}
+static struct notifier_block hyperv_panic_vmbus_unload_block = {
+	.notifier_call	= hv_panic_vmbus_unload,
+	.priority	= INT_MIN + 1, /* almost the latest one to execute */
+};
+
+/*
+ * The following callback works both as die and panic notifier; its
+ * goal is to provide panic information to the hypervisor unless the
+ * kmsg dumper is gonna be used [see hv_kmsg_dump()], which provides
+ * more information but is not always available.
+ *
+ * Notice that both the panic/die report notifiers are registered only
+ * if we have the capability HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE set.
+ */
+static int hv_die_panic_notify_crash(struct notifier_block *nb,
+				     unsigned long val, void *args)
 {
 	struct pt_regs *regs;
+	bool is_die;
 
-	vmbus_initiate_unload(true);
-
-	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
-	 */
-	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE
-	    && hyperv_report_reg()) {
+	/* Don't notify Hyper-V unless we have a die oops event or panic. */
+	switch (val) {
+	case DIE_OOPS:
+		is_die = true;
+		regs = ((struct die_args *)args)->regs;
+		break;
+	case PANIC_NOTIFIER:
+		is_die = false;
 		regs = current_pt_regs();
-		hyperv_report_panic(regs, val, false);
-	}
-	return NOTIFY_DONE;
-}
-
-static int hyperv_die_event(struct notifier_block *nb, unsigned long val,
-			    void *args)
-{
-	struct die_args *die = args;
-	struct pt_regs *regs = die->regs;
-
-	/* Don't notify Hyper-V if the die event is other than oops */
-	if (val != DIE_OOPS)
+		break;
+	default:
 		return NOTIFY_DONE;
+	}
 
 	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
+	 * Hyper-V should be notified only once about a panic/die. If we will
+	 * be calling hv_kmsg_dump() later with kmsg data, don't do the
+	 * notification here.
 	 */
 	if (hyperv_report_reg())
-		hyperv_report_panic(regs, val, true);
+		hyperv_report_panic(regs, val, is_die);
+
 	return NOTIFY_DONE;
 }
-
-static struct notifier_block hyperv_die_block = {
-	.notifier_call = hyperv_die_event,
+static struct notifier_block hyperv_die_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
-static struct notifier_block hyperv_panic_block = {
-	.notifier_call = hyperv_panic_event,
+static struct notifier_block hyperv_panic_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
 
 static const char *fb_mmio_name = "fb_range";
@@ -1589,16 +1613,17 @@ static int vmbus_bus_init(void)
 		if (hyperv_crash_ctl & HV_CRASH_CTL_CRASH_NOTIFY_MSG)
 			hv_kmsg_dump_register();
 
-		register_die_notifier(&hyperv_die_block);
+		register_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_register(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * Always register the panic notifier because we need to unload
-	 * the VMbus channel connection to prevent any VMbus
-	 * activity after the VM panics.
+	 * Always register the vmbus unload panic notifier because we
+	 * need to shut the VMbus channel connection on panic.
 	 */
 	atomic_notifier_chain_register(&panic_notifier_list,
-			       &hyperv_panic_block);
+			       &hyperv_panic_vmbus_unload_block);
 
 	vmbus_request_offers();
 
@@ -2817,15 +2842,17 @@ 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_block);
+		unregister_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_unregister(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * The panic notifier is always registered, hence we should
+	 * The vmbus panic notifier is always registered, hence we should
 	 * also unconditionally unregister it here as well.
 	 */
 	atomic_notifier_chain_unregister(&panic_notifier_list,
-					 &hyperv_panic_block);
+					&hyperv_panic_vmbus_unload_block);
 
 	free_page((unsigned long)hv_panic_page);
 	unregister_sysctl_table(hv_ctl_table_hdr);
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index c8e0ea27caf1..f3494b868a64 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1244,7 +1244,15 @@ static int hvfb_probe(struct hv_device *hdev,
 	par->fb_ready = true;
 
 	par->synchronous_fb = false;
+
+	/*
+	 * We need to be sure this panic notifier runs _before_ the
+	 * vmbus disconnect, so order it by priority. It must execute
+	 * before the function hv_panic_vmbus_unload() [drivers/hv/vmbus_drv.c],
+	 * which is almost at the end of list, with priority = INT_MIN + 1.
+	 */
 	par->hvfb_panic_nb.notifier_call = hvfb_on_panic;
+	par->hvfb_panic_nb.priority = INT_MIN + 10,
 	atomic_notifier_chain_register(&panic_notifier_list,
 				       &par->hvfb_panic_nb);
 
-- 
2.36.0


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


WARNING: multiple messages have this Message-ID (diff)
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: akpm@linux-foundation.org, bhe@redhat.com, pmladek@suse.com,
	kexec@lists.infradead.org
Cc: linux-kernel@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	coresight@lists.linaro.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-pm@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, gpiccoli@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.
Subject: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers
Date: Wed, 27 Apr 2022 19:49:10 -0300	[thread overview]
Message-ID: <20220427224924.592546-17-gpiccoli@igalia.com> (raw)
In-Reply-To: <20220427224924.592546-1-gpiccoli@igalia.com>

Currently Hyper-V guests are among the most relevant users of the panic
infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
both in cleaning-up procedures (closing a hypervisor <-> guest connection,
disabling a paravirtualized timer) as well as to data collection (sending
panic information to the hypervisor) and framebuffer management.

The thing is: some notifiers are related to others, ordering matters, some
functionalities are duplicated and there are lots of conditionals behind
sending panic information to the hypervisor. This patch, as part of an
effort to clean-up the panic notifiers mechanism and better document
things, address some of the issues/complexities of Hyper-V panic handling
through the following changes:

(a) We have die and panic notifiers on vmbus_drv.c and both have goals of
sending panic information to the hypervisor, though the panic notifier is
also responsible for a cleaning-up procedure.

This commit clears the code by splitting the panic notifier in two, one
for closing the vmbus connection whereas the other is only for sending
panic info to hypervisor. With that, it was possible to merge the die and
panic notifiers in a single/well-documented function, and clear some
conditional complexities on sending such information to the hypervisor.

(b) The new panic notifier created after (a) is only doing a single thing:
cleaning the vmbus connection. This procedure might cause a delay (due to
hypervisor I/O completion), so we postpone that to run late. But more
relevant: this *same* vmbus unloading happens in the crash_shutdown()
handler, so if kdump is set, we can safely skip this panic notifier and
defer such clean-up to the kexec crash handler.

(c) There is also a Hyper-V framebuffer panic notifier, which relies in
doing a vmbus operation that demands a valid connection. So, we must
order this notifier with the panic notifier from vmbus_drv.c, in order to
guarantee that the framebuffer code executes before the vmbus connection
is unloaded.

Also, this commit removes a useless header.

Although there is code rework and re-ordering, we expect that this change
has no functional regressions but instead optimize the path and increase
panic reliability on Hyper-V. This was tested on Hyper-V with success.

Fixes: 792f232d57ff ("Drivers: hv: vmbus: Fix potential crash on module unload")
Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Tianyu Lan <Tianyu.Lan@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Tested-by: Fabio A M Martins <fabiomirmar@gmail.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
---

Special thanks to Michael Kelley for the good information about the Hyper-V
panic path in email threads some months ago, and to Fabio for the testing
performed.

Michael and all Microsoft folks: a careful analysis to double-check our changes
and assumptions here is really appreciated, this code is complex and intricate,
it is possible some corner case might have been overlooked.

Thanks in advance!

 drivers/hv/vmbus_drv.c          | 109 ++++++++++++++++++++------------
 drivers/video/fbdev/hyperv_fb.c |   8 +++
 2 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 14de17087864..f37f12d48001 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -24,11 +24,11 @@
 #include <linux/sched/task_stack.h>
 
 #include <linux/delay.h>
-#include <linux/notifier.h>
 #include <linux/panic_notifier.h>
 #include <linux/ptrace.h>
 #include <linux/screen_info.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/efi.h>
 #include <linux/random.h>
 #include <linux/kernel.h>
@@ -68,51 +68,75 @@ static int hyperv_report_reg(void)
 	return !sysctl_record_panic_msg || !hv_panic_page;
 }
 
-static int hyperv_panic_event(struct notifier_block *nb, unsigned long val,
+/*
+ * The panic notifier below is responsible solely for unloading the
+ * vmbus connection, which is necessary in a panic event. But notice
+ * that this same unloading procedure is executed in the Hyper-V
+ * crash_shutdown() handler [see hv_crash_handler()], which basically
+ * means that we can postpone its execution if we have kdump set,
+ * since it will run the crash_shutdown() handler anyway. Even more
+ * intrincated is the relation of this notifier with Hyper-V framebuffer
+ * panic notifier - we need vmbus connection alive there in order to
+ * succeed, so we need to order both with each other [for reference see
+ * hvfb_on_panic()] - this is done using notifiers' priorities.
+ */
+static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
 			      void *args)
+{
+	if (!kexec_crash_loaded())
+		vmbus_initiate_unload(true);
+
+	return NOTIFY_DONE;
+}
+static struct notifier_block hyperv_panic_vmbus_unload_block = {
+	.notifier_call	= hv_panic_vmbus_unload,
+	.priority	= INT_MIN + 1, /* almost the latest one to execute */
+};
+
+/*
+ * The following callback works both as die and panic notifier; its
+ * goal is to provide panic information to the hypervisor unless the
+ * kmsg dumper is gonna be used [see hv_kmsg_dump()], which provides
+ * more information but is not always available.
+ *
+ * Notice that both the panic/die report notifiers are registered only
+ * if we have the capability HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE set.
+ */
+static int hv_die_panic_notify_crash(struct notifier_block *nb,
+				     unsigned long val, void *args)
 {
 	struct pt_regs *regs;
+	bool is_die;
 
-	vmbus_initiate_unload(true);
-
-	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
-	 */
-	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE
-	    && hyperv_report_reg()) {
+	/* Don't notify Hyper-V unless we have a die oops event or panic. */
+	switch (val) {
+	case DIE_OOPS:
+		is_die = true;
+		regs = ((struct die_args *)args)->regs;
+		break;
+	case PANIC_NOTIFIER:
+		is_die = false;
 		regs = current_pt_regs();
-		hyperv_report_panic(regs, val, false);
-	}
-	return NOTIFY_DONE;
-}
-
-static int hyperv_die_event(struct notifier_block *nb, unsigned long val,
-			    void *args)
-{
-	struct die_args *die = args;
-	struct pt_regs *regs = die->regs;
-
-	/* Don't notify Hyper-V if the die event is other than oops */
-	if (val != DIE_OOPS)
+		break;
+	default:
 		return NOTIFY_DONE;
+	}
 
 	/*
-	 * Hyper-V should be notified only once about a panic.  If we will be
-	 * doing hv_kmsg_dump() with kmsg data later, don't do the notification
-	 * here.
+	 * Hyper-V should be notified only once about a panic/die. If we will
+	 * be calling hv_kmsg_dump() later with kmsg data, don't do the
+	 * notification here.
 	 */
 	if (hyperv_report_reg())
-		hyperv_report_panic(regs, val, true);
+		hyperv_report_panic(regs, val, is_die);
+
 	return NOTIFY_DONE;
 }
-
-static struct notifier_block hyperv_die_block = {
-	.notifier_call = hyperv_die_event,
+static struct notifier_block hyperv_die_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
-static struct notifier_block hyperv_panic_block = {
-	.notifier_call = hyperv_panic_event,
+static struct notifier_block hyperv_panic_report_block = {
+	.notifier_call = hv_die_panic_notify_crash,
 };
 
 static const char *fb_mmio_name = "fb_range";
@@ -1589,16 +1613,17 @@ static int vmbus_bus_init(void)
 		if (hyperv_crash_ctl & HV_CRASH_CTL_CRASH_NOTIFY_MSG)
 			hv_kmsg_dump_register();
 
-		register_die_notifier(&hyperv_die_block);
+		register_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_register(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * Always register the panic notifier because we need to unload
-	 * the VMbus channel connection to prevent any VMbus
-	 * activity after the VM panics.
+	 * Always register the vmbus unload panic notifier because we
+	 * need to shut the VMbus channel connection on panic.
 	 */
 	atomic_notifier_chain_register(&panic_notifier_list,
-			       &hyperv_panic_block);
+			       &hyperv_panic_vmbus_unload_block);
 
 	vmbus_request_offers();
 
@@ -2817,15 +2842,17 @@ 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_block);
+		unregister_die_notifier(&hyperv_die_report_block);
+		atomic_notifier_chain_unregister(&panic_notifier_list,
+						&hyperv_panic_report_block);
 	}
 
 	/*
-	 * The panic notifier is always registered, hence we should
+	 * The vmbus panic notifier is always registered, hence we should
 	 * also unconditionally unregister it here as well.
 	 */
 	atomic_notifier_chain_unregister(&panic_notifier_list,
-					 &hyperv_panic_block);
+					&hyperv_panic_vmbus_unload_block);
 
 	free_page((unsigned long)hv_panic_page);
 	unregister_sysctl_table(hv_ctl_table_hdr);
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index c8e0ea27caf1..f3494b868a64 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1244,7 +1244,15 @@ static int hvfb_probe(struct hv_device *hdev,
 	par->fb_ready = true;
 
 	par->synchronous_fb = false;
+
+	/*
+	 * We need to be sure this panic notifier runs _before_ the
+	 * vmbus disconnect, so order it by priority. It must execute
+	 * before the function hv_panic_vmbus_unload() [drivers/hv/vmbus_drv.c],
+	 * which is almost at the end of list, with priority = INT_MIN + 1.
+	 */
 	par->hvfb_panic_nb.notifier_call = hvfb_on_panic;
+	par->hvfb_panic_nb.priority = INT_MIN + 10,
 	atomic_notifier_chain_register(&panic_notifier_list,
 				       &par->hvfb_panic_nb);
 
-- 
2.36.0

  parent reply	other threads:[~2022-04-27 22:57 UTC|newest]

Thread overview: 877+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 22:48 [PATCH 00/30] The panic notifiers refactor Guilherme G. Piccoli
2022-04-27 22:48 ` Guilherme G. Piccoli
2022-04-27 22:48 ` Guilherme G. Piccoli
2022-04-27 22:48 ` Guilherme G. Piccoli
2022-04-27 22:48 ` [PATCH 01/30] x86/crash,reboot: Avoid re-disabling VMX in all CPUs on crash/restart Guilherme G. Piccoli
2022-04-27 22:48   ` [PATCH 01/30] x86/crash, reboot: " Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-05-09 12:32   ` [PATCH 01/30] x86/crash,reboot: " Guilherme G. Piccoli
2022-05-09 12:32     ` Guilherme G. Piccoli
2022-05-09 12:32     ` Guilherme G. Piccoli
2022-05-09 12:32     ` Guilherme G. Piccoli
2022-05-09 12:32     ` Guilherme G. Piccoli
2022-05-09 15:52   ` Sean Christopherson
2022-05-09 15:52     ` Sean Christopherson
2022-05-09 15:52     ` Sean Christopherson
2022-05-09 15:52     ` Sean Christopherson
2022-05-09 15:52     ` Sean Christopherson
2022-05-10 20:11     ` Guilherme G. Piccoli
2022-05-10 20:11       ` Guilherme G. Piccoli
2022-05-10 20:11       ` Guilherme G. Piccoli
2022-05-10 20:11       ` Guilherme G. Piccoli
2022-05-10 20:11       ` Guilherme G. Piccoli
2022-04-27 22:48 ` [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-29 16:26   ` Michael Kelley (LINUX)
2022-04-29 16:26     ` Michael Kelley (LINUX)
2022-04-29 16:26     ` Michael Kelley
2022-04-29 16:26     ` Michael Kelley (LINUX)
2022-04-29 18:20   ` Marc Zyngier
2022-04-29 18:20     ` Marc Zyngier
2022-04-29 18:20     ` Marc Zyngier
2022-04-29 18:20     ` Marc Zyngier
2022-04-29 18:20     ` Marc Zyngier
2022-04-29 21:38     ` Guilherme G. Piccoli
2022-04-29 21:38       ` Guilherme G. Piccoli
2022-04-29 21:38       ` Guilherme G. Piccoli
2022-04-29 21:38       ` Guilherme G. Piccoli
2022-04-29 21:38       ` Guilherme G. Piccoli
2022-04-29 21:45       ` Russell King (Oracle)
2022-04-29 21:45         ` Russell King (Oracle)
2022-04-29 21:45         ` Russell King (Oracle)
2022-04-29 21:45         ` Russell King
2022-04-29 21:45         ` Russell King (Oracle)
2022-04-29 21:56         ` Guilherme G. Piccoli
2022-04-29 21:56           ` Guilherme G. Piccoli
2022-04-29 21:56           ` Guilherme G. Piccoli
2022-04-29 21:56           ` Guilherme G. Piccoli
2022-04-29 21:56           ` Guilherme G. Piccoli
2022-04-29 22:00         ` Marc Zyngier
2022-04-29 22:00           ` Marc Zyngier
2022-04-29 22:00           ` Marc Zyngier
2022-04-29 22:00           ` Marc Zyngier
2022-04-29 22:00           ` Marc Zyngier
2022-04-27 22:48 ` [PATCH 03/30] notifier: Add panic notifiers info and purge trailing whitespaces Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48 ` [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-05-03 18:03   ` Evan Green
2022-05-03 18:03     ` Evan Green
2022-05-03 18:03     ` Evan Green
2022-05-03 18:03     ` Evan Green
2022-05-03 18:03     ` Evan Green
2022-05-03 19:12     ` Guilherme G. Piccoli
2022-05-03 19:12       ` Guilherme G. Piccoli
2022-05-03 19:12       ` Guilherme G. Piccoli
2022-05-03 19:12       ` Guilherme G. Piccoli
2022-05-03 19:12       ` Guilherme G. Piccoli
2022-05-03 21:56       ` Evan Green
2022-05-03 21:56         ` Evan Green
2022-05-03 21:56         ` Evan Green
2022-05-03 21:56         ` Evan Green
2022-05-03 21:56         ` Evan Green
2022-05-04 12:45         ` Guilherme G. Piccoli
2022-05-04 12:45           ` Guilherme G. Piccoli
2022-05-04 12:45           ` Guilherme G. Piccoli
2022-05-04 12:45           ` Guilherme G. Piccoli
2022-05-04 12:45           ` Guilherme G. Piccoli
2022-05-10 11:38       ` Petr Mladek
2022-05-10 11:38         ` Petr Mladek
2022-05-10 11:38         ` Petr Mladek
2022-05-10 11:38         ` Petr Mladek
2022-05-10 11:38         ` Petr Mladek
2022-05-10 13:04         ` Guilherme G. Piccoli
2022-05-10 13:04           ` Guilherme G. Piccoli
2022-05-10 13:04           ` Guilherme G. Piccoli
2022-05-10 13:04           ` Guilherme G. Piccoli
2022-05-10 13:04           ` Guilherme G. Piccoli
2022-05-10 17:20         ` Steven Rostedt
2022-05-10 17:20           ` Steven Rostedt
2022-05-10 17:20           ` Steven Rostedt
2022-05-10 17:20           ` Steven Rostedt
2022-05-10 17:20           ` Steven Rostedt
2022-05-10 19:40           ` John Ogness
2022-05-10 19:40             ` John Ogness
2022-05-10 19:40             ` John Ogness
2022-05-10 19:40             ` John Ogness
2022-05-10 19:40             ` John Ogness
2022-05-11 11:13             ` Petr Mladek
2022-05-11 11:13               ` Petr Mladek
2022-05-11 11:13               ` Petr Mladek
2022-05-11 11:13               ` Petr Mladek
2022-05-11 11:13               ` Petr Mladek
2022-04-27 22:48 ` [PATCH 05/30] misc/pvpanic: " Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-04-27 22:48   ` Guilherme G. Piccoli
2022-05-10 12:14   ` Petr Mladek
2022-05-10 12:14     ` Petr Mladek
2022-05-10 12:14     ` Petr Mladek
2022-05-10 12:14     ` Petr Mladek
2022-05-10 12:14     ` Petr Mladek
2022-05-10 13:00     ` Guilherme G. Piccoli
2022-05-10 13:00       ` Guilherme G. Piccoli
2022-05-10 13:00       ` Guilherme G. Piccoli
2022-05-10 13:00       ` Guilherme G. Piccoli
2022-05-10 13:00       ` Guilherme G. Piccoli
2022-05-17 10:58       ` Petr Mladek
2022-05-17 10:58         ` Petr Mladek
2022-05-17 10:58         ` Petr Mladek
2022-05-17 10:58         ` Petr Mladek
2022-05-17 10:58         ` Petr Mladek
2022-05-17 13:03         ` Guilherme G. Piccoli
2022-05-17 13:03           ` Guilherme G. Piccoli
2022-05-17 13:03           ` Guilherme G. Piccoli
2022-05-17 13:03           ` Guilherme G. Piccoli
2022-05-17 13:03           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 06/30] soc: bcm: brcmstb: Document panic notifier action and remove useless header Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-02 15:38   ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:47     ` Guilherme G. Piccoli
2022-05-02 15:47       ` Guilherme G. Piccoli
2022-05-02 15:47       ` Guilherme G. Piccoli
2022-05-02 15:47       ` Guilherme G. Piccoli
2022-05-02 15:47       ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 07/30] mips: ip22: Reword PANICED to PANICKED " Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-04 20:32   ` Thomas Bogendoerfer
2022-05-04 20:32     ` Thomas Bogendoerfer
2022-05-04 20:32     ` Thomas Bogendoerfer
2022-05-04 20:32     ` Thomas Bogendoerfer
2022-05-04 20:32     ` Thomas Bogendoerfer
2022-05-04 21:26     ` Guilherme G. Piccoli
2022-05-04 21:26       ` Guilherme G. Piccoli
2022-05-04 21:26       ` Guilherme G. Piccoli
2022-05-04 21:26       ` Guilherme G. Piccoli
2022-05-04 21:26       ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 08/30] powerpc/setup: Refactor/untangle panic notifiers Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-05 18:55   ` Hari Bathini
2022-05-05 18:55     ` Hari Bathini
2022-05-05 18:55     ` Hari Bathini
2022-05-05 18:55     ` Hari Bathini
2022-05-05 18:55     ` Hari Bathini
2022-05-05 19:28     ` Guilherme G. Piccoli
2022-05-05 19:28       ` Guilherme G. Piccoli
2022-05-05 19:28       ` Guilherme G. Piccoli
2022-05-05 19:28       ` Guilherme G. Piccoli
2022-05-05 19:28       ` Guilherme G. Piccoli
2022-05-09 12:50     ` Guilherme G. Piccoli
2022-05-09 12:50       ` Guilherme G. Piccoli
2022-05-09 12:50       ` Guilherme G. Piccoli
2022-05-09 12:50       ` Guilherme G. Piccoli
2022-05-09 12:50       ` Guilherme G. Piccoli
2022-05-10 13:53       ` Michael Ellerman
2022-05-10 13:53         ` Michael Ellerman
2022-05-10 13:53         ` Michael Ellerman
2022-05-10 13:53         ` Michael Ellerman
2022-05-10 13:53         ` Michael Ellerman
2022-05-10 14:10         ` Guilherme G. Piccoli
2022-05-10 14:10           ` Guilherme G. Piccoli
2022-05-10 14:10           ` Guilherme G. Piccoli
2022-05-10 14:10           ` Guilherme G. Piccoli
2022-05-10 14:10           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 09/30] coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-28  8:11   ` Suzuki K Poulose
2022-04-28  8:11     ` Suzuki K Poulose
2022-04-28  8:11     ` Suzuki K Poulose
2022-04-28  8:11     ` Suzuki K Poulose
2022-04-28  8:11     ` Suzuki K Poulose
2022-04-29 14:01     ` Guilherme G. Piccoli
2022-04-29 14:01       ` Guilherme G. Piccoli
2022-04-29 14:01       ` Guilherme G. Piccoli
2022-04-29 14:01       ` Guilherme G. Piccoli
2022-04-29 14:01       ` Guilherme G. Piccoli
2022-05-09 13:09     ` Guilherme G. Piccoli
2022-05-09 13:09       ` Guilherme G. Piccoli
2022-05-09 13:09       ` Guilherme G. Piccoli
2022-05-09 13:09       ` Guilherme G. Piccoli
2022-05-09 13:09       ` Guilherme G. Piccoli
2022-05-09 16:14       ` Suzuki K Poulose
2022-05-09 16:14         ` Suzuki K Poulose
2022-05-09 16:14         ` Suzuki K Poulose
2022-05-09 16:14         ` Suzuki K Poulose
2022-05-09 16:14         ` Suzuki K Poulose
2022-05-09 16:26         ` Guilherme G. Piccoli
2022-05-09 16:26           ` Guilherme G. Piccoli
2022-05-09 16:26           ` Guilherme G. Piccoli
2022-05-09 16:26           ` Guilherme G. Piccoli
2022-05-09 16:26           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 10/30] alpha: Clean-up the panic notifier code Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-09 14:13   ` Guilherme G. Piccoli
2022-05-09 14:13     ` Guilherme G. Piccoli
2022-05-09 14:13     ` Guilherme G. Piccoli
2022-05-09 14:13     ` Guilherme G. Piccoli
2022-05-09 14:13     ` Guilherme G. Piccoli
2022-05-10 14:16     ` Petr Mladek
2022-05-10 14:16       ` Petr Mladek
2022-05-10 14:16       ` Petr Mladek
2022-05-10 14:16       ` Petr Mladek
2022-05-10 14:16       ` Petr Mladek
2022-05-11 20:10       ` Guilherme G. Piccoli
2022-05-11 20:10         ` Guilherme G. Piccoli
2022-05-11 20:10         ` Guilherme G. Piccoli
2022-05-11 20:10         ` Guilherme G. Piccoli
2022-05-11 20:10         ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 11/30] um: Improve panic notifiers consistency and ordering Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-28  8:30   ` Johannes Berg
2022-04-29 15:46     ` Guilherme G. Piccoli
2022-05-10 14:28   ` Petr Mladek
2022-05-10 14:28     ` Petr Mladek
2022-05-10 14:28     ` Petr Mladek
2022-05-10 14:28     ` Petr Mladek
2022-05-10 14:28     ` Petr Mladek
2022-05-11 20:22     ` Guilherme G. Piccoli
2022-05-11 20:22       ` Guilherme G. Piccoli
2022-05-11 20:22       ` Guilherme G. Piccoli
2022-05-11 20:22       ` Guilherme G. Piccoli
2022-05-11 20:22       ` Guilherme G. Piccoli
2022-05-13 14:44       ` Johannes Berg
2022-05-13 14:44         ` Johannes Berg
2022-05-13 14:44         ` Johannes Berg
2022-05-13 14:44         ` Johannes Berg
2022-05-13 14:44         ` Johannes Berg
2022-05-15 22:12         ` Guilherme G. Piccoli
2022-05-15 22:12           ` Guilherme G. Piccoli
2022-05-15 22:12           ` Guilherme G. Piccoli
2022-05-15 22:12           ` Guilherme G. Piccoli
2022-05-15 22:12           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 12/30] parisc: Replace regular spinlock with spin_trylock on panic path Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-28 16:55   ` Helge Deller
2022-04-28 16:55     ` Helge Deller
2022-04-28 16:55     ` Helge Deller
2022-04-28 16:55     ` Helge Deller
2022-04-28 16:55     ` Helge Deller
2022-04-29 14:34     ` Guilherme G. Piccoli
2022-04-29 14:34       ` Guilherme G. Piccoli
2022-04-29 14:34       ` Guilherme G. Piccoli
2022-04-29 14:34       ` Guilherme G. Piccoli
2022-04-29 14:34       ` Guilherme G. Piccoli
2022-05-23 20:40     ` Guilherme G. Piccoli
2022-05-23 20:40       ` Guilherme G. Piccoli
2022-05-23 20:40       ` Guilherme G. Piccoli
2022-05-23 20:40       ` Guilherme G. Piccoli
2022-05-23 20:40       ` Guilherme G. Piccoli
2022-05-23 21:31       ` Helge Deller
2022-05-23 21:55         ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 13/30] s390/consoles: Improve panic notifiers reliability Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-29 18:46   ` Heiko Carstens
2022-04-29 18:46     ` Heiko Carstens
2022-04-29 18:46     ` Heiko Carstens
2022-04-29 18:46     ` Heiko Carstens
2022-04-29 18:46     ` Heiko Carstens
2022-04-29 19:31     ` Guilherme G. Piccoli
2022-04-29 19:31       ` Guilherme G. Piccoli
2022-04-29 19:31       ` Guilherme G. Piccoli
2022-04-29 19:31       ` Guilherme G. Piccoli
2022-04-29 19:31       ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 14/30] panic: Properly identify the panic event to the notifiers' callbacks Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-10 15:16   ` Petr Mladek
2022-05-10 15:16     ` Petr Mladek via Openipmi-developer
2022-05-10 15:16     ` Petr Mladek
2022-05-10 15:16     ` Petr Mladek
2022-05-10 15:16     ` Petr Mladek
2022-05-10 16:16     ` Guilherme G. Piccoli
2022-05-10 16:16       ` Guilherme G. Piccoli
2022-05-10 16:16       ` Guilherme G. Piccoli
2022-05-10 16:16       ` Guilherme G. Piccoli
2022-05-10 16:16       ` Guilherme G. Piccoli
2022-05-17 13:11       ` Petr Mladek
2022-05-17 13:11         ` Petr Mladek
2022-05-17 13:11         ` Petr Mladek
2022-05-17 13:11         ` Petr Mladek
2022-05-17 13:11         ` Petr Mladek
2022-05-17 15:19         ` Guilherme G. Piccoli
2022-05-17 15:19           ` Guilherme G. Piccoli
2022-05-17 15:19           ` Guilherme G. Piccoli
2022-05-17 15:19           ` Guilherme G. Piccoli
2022-05-17 15:19           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 15/30] bus: brcmstb_gisb: Clean-up panic/die notifiers Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-02 15:38   ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:38     ` Florian Fainelli
2022-05-02 15:50     ` Guilherme G. Piccoli
2022-05-02 15:50       ` Guilherme G. Piccoli
2022-05-02 15:50       ` Guilherme G. Piccoli
2022-05-02 15:50       ` Guilherme G. Piccoli
2022-05-02 15:50       ` Guilherme G. Piccoli
2022-05-10 15:28   ` Petr Mladek
2022-05-10 15:28     ` Petr Mladek
2022-05-10 15:28     ` Petr Mladek
2022-05-10 15:28     ` Petr Mladek
2022-05-10 15:28     ` Petr Mladek
2022-05-17 15:32     ` Guilherme G. Piccoli
2022-05-17 15:32       ` Guilherme G. Piccoli
2022-05-17 15:32       ` Guilherme G. Piccoli
2022-05-17 15:32       ` Guilherme G. Piccoli
2022-05-17 15:32       ` Guilherme G. Piccoli
2022-04-27 22:49 ` Guilherme G. Piccoli [this message]
2022-04-27 22:49   ` [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-29 17:16   ` Michael Kelley (LINUX)
2022-04-29 17:16     ` Michael Kelley (LINUX)
2022-04-29 17:16     ` Michael Kelley
2022-04-29 17:16     ` Michael Kelley (LINUX)
2022-04-29 22:35     ` Guilherme G. Piccoli
2022-04-29 22:35       ` Guilherme G. Piccoli
2022-04-29 22:35       ` Guilherme G. Piccoli
2022-04-29 22:35       ` Guilherme G. Piccoli
2022-04-29 22:35       ` Guilherme G. Piccoli
2022-05-03 18:13       ` Michael Kelley (LINUX)
2022-05-03 18:13         ` Michael Kelley (LINUX)
2022-05-03 18:13         ` Michael Kelley
2022-05-03 18:13         ` Michael Kelley (LINUX)
2022-05-03 18:57         ` Guilherme G. Piccoli
2022-05-03 18:57           ` Guilherme G. Piccoli
2022-05-03 18:57           ` Guilherme G. Piccoli
2022-05-03 18:57           ` Guilherme G. Piccoli
2022-05-03 18:57           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 17/30] tracing: Improve panic/die notifiers Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-29  9:22   ` Sergei Shtylyov
2022-04-29  9:22     ` Sergei Shtylyov
2022-04-29  9:22     ` Sergei Shtylyov
2022-04-29  9:22     ` Sergei Shtylyov
2022-04-29  9:22     ` Sergei Shtylyov
2022-04-29 13:23     ` Steven Rostedt
2022-04-29 13:23       ` Steven Rostedt
2022-04-29 13:23       ` Steven Rostedt
2022-04-29 13:23       ` Steven Rostedt
2022-04-29 13:23       ` Steven Rostedt
2022-04-29 13:46       ` Guilherme G. Piccoli
2022-04-29 13:46         ` Guilherme G. Piccoli
2022-04-29 13:46         ` Guilherme G. Piccoli
2022-04-29 13:46         ` Guilherme G. Piccoli
2022-04-29 13:46         ` Guilherme G. Piccoli
2022-04-29 13:56         ` Steven Rostedt
2022-04-29 13:56           ` Steven Rostedt
2022-04-29 13:56           ` Steven Rostedt
2022-04-29 13:56           ` Steven Rostedt
2022-04-29 13:56           ` Steven Rostedt
2022-04-29 14:44           ` Guilherme G. Piccoli
2022-04-29 14:44             ` Guilherme G. Piccoli
2022-04-29 14:44             ` Guilherme G. Piccoli
2022-04-29 14:44             ` Guilherme G. Piccoli
2022-04-29 14:44             ` Guilherme G. Piccoli
2022-05-11 11:45   ` Petr Mladek
2022-05-11 11:45     ` Petr Mladek
2022-05-11 11:45     ` Petr Mladek
2022-05-11 11:45     ` Petr Mladek
2022-05-11 11:45     ` Petr Mladek
2022-05-17 15:33     ` Guilherme G. Piccoli
2022-05-17 15:33       ` Guilherme G. Piccoli
2022-05-17 15:33       ` Guilherme G. Piccoli
2022-05-17 15:33       ` Guilherme G. Piccoli
2022-05-17 15:33       ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 18/30] notifier: Show function names on notifier routines if DEBUG_NOTIFIERS is set Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-28  1:01   ` Xiaoming Ni
2022-04-28  1:01     ` Xiaoming Ni
2022-04-28  1:01     ` Xiaoming Ni
2022-04-28  1:01     ` Xiaoming Ni
2022-04-28  1:01     ` Xiaoming Ni
2022-04-29 19:38     ` Guilherme G. Piccoli
2022-04-29 19:38       ` Guilherme G. Piccoli
2022-04-29 19:38       ` Guilherme G. Piccoli
2022-04-29 19:38       ` Guilherme G. Piccoli
2022-04-29 19:38       ` Guilherme G. Piccoli
2022-05-10 17:29     ` Steven Rostedt
2022-05-10 17:29       ` Steven Rostedt
2022-05-10 17:29       ` Steven Rostedt
2022-05-10 17:29       ` Steven Rostedt
2022-05-10 17:29       ` Steven Rostedt
2022-05-16 16:14       ` Guilherme G. Piccoli
2022-05-16 16:14         ` Guilherme G. Piccoli
2022-05-16 16:14         ` Guilherme G. Piccoli
2022-05-16 16:14         ` Guilherme G. Piccoli
2022-05-16 16:14         ` Guilherme G. Piccoli
2022-04-29 16:27   ` Michael Kelley (LINUX)
2022-04-29 16:27     ` Michael Kelley (LINUX)
2022-04-29 16:27     ` Michael Kelley
2022-04-29 16:27     ` Michael Kelley (LINUX)
2022-04-27 22:49 ` [PATCH 19/30] panic: Add the panic hypervisor notifier list Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-29 17:30   ` Michael Kelley (LINUX)
2022-04-29 17:30     ` Michael Kelley (LINUX)
2022-04-29 17:30     ` Michael Kelley
2022-04-29 17:30     ` Michael Kelley (LINUX)
2022-04-29 18:04     ` Guilherme G. Piccoli
2022-04-29 18:04       ` Guilherme G. Piccoli
2022-04-29 18:04       ` Guilherme G. Piccoli
2022-04-29 18:04       ` Guilherme G. Piccoli
2022-04-29 18:04       ` Guilherme G. Piccoli
2022-05-03 17:44       ` Michael Kelley (LINUX)
2022-05-03 17:44         ` Michael Kelley (LINUX)
2022-05-03 17:44         ` Michael Kelley
2022-05-03 17:44         ` Michael Kelley (LINUX)
2022-05-03 17:56         ` Guilherme G. Piccoli
2022-05-03 17:56           ` Guilherme G. Piccoli
2022-05-03 17:56           ` Guilherme G. Piccoli
2022-05-03 17:56           ` Guilherme G. Piccoli
2022-05-03 17:56           ` Guilherme G. Piccoli
2022-05-16 14:01   ` Petr Mladek
2022-05-16 14:01     ` Petr Mladek
2022-05-16 14:01     ` Petr Mladek
2022-05-16 14:01     ` Petr Mladek
2022-05-16 14:01     ` Petr Mladek
2022-05-16 15:06     ` Guilherme G. Piccoli
2022-05-16 15:06       ` Guilherme G. Piccoli
2022-05-16 15:06       ` Guilherme G. Piccoli
2022-05-16 15:06       ` Guilherme G. Piccoli
2022-05-16 15:06       ` Guilherme G. Piccoli
2022-05-16 16:02       ` Evan Green
2022-05-16 16:02         ` Evan Green
2022-05-16 16:02         ` Evan Green
2022-05-16 16:02         ` Evan Green
2022-05-16 16:02         ` Evan Green
2022-05-17 13:28         ` Petr Mladek
2022-05-17 13:28           ` Petr Mladek
2022-05-17 13:28           ` Petr Mladek
2022-05-17 13:28           ` Petr Mladek
2022-05-17 13:28           ` Petr Mladek
2022-05-17 16:37           ` Guilherme G. Piccoli
2022-05-17 16:37             ` Guilherme G. Piccoli
2022-05-17 16:37             ` Guilherme G. Piccoli
2022-05-17 16:37             ` Guilherme G. Piccoli
2022-05-17 16:37             ` Guilherme G. Piccoli
2022-05-18  7:33             ` Petr Mladek
2022-05-18  7:33               ` Petr Mladek
2022-05-18  7:33               ` Petr Mladek
2022-05-18  7:33               ` Petr Mladek
2022-05-18 13:24               ` Guilherme G. Piccoli
2022-05-18 13:24                 ` Guilherme G. Piccoli
2022-05-18 13:24                 ` Guilherme G. Piccoli
2022-05-18 13:24                 ` Guilherme G. Piccoli
2022-05-18 13:24                 ` Guilherme G. Piccoli
2022-05-17 13:57       ` Petr Mladek
2022-05-17 13:57         ` Petr Mladek
2022-05-17 13:57         ` Petr Mladek
2022-05-17 13:57         ` Petr Mladek
2022-05-17 13:57         ` Petr Mladek
2022-05-17 16:42         ` Guilherme G. Piccoli
2022-05-17 16:42           ` Guilherme G. Piccoli
2022-05-17 16:42           ` Guilherme G. Piccoli
2022-05-17 16:42           ` Guilherme G. Piccoli
2022-05-17 16:42           ` Guilherme G. Piccoli
2022-05-18  7:38           ` Petr Mladek
2022-05-18  7:38             ` Petr Mladek
2022-05-18  7:38             ` Petr Mladek
2022-05-18  7:38             ` Petr Mladek
2022-05-18  7:38             ` Petr Mladek
2022-05-18 13:09             ` Guilherme G. Piccoli
2022-05-18 13:09               ` Guilherme G. Piccoli
2022-05-18 13:09               ` Guilherme G. Piccoli
2022-05-18 13:09               ` Guilherme G. Piccoli
2022-05-18 13:09               ` Guilherme G. Piccoli
2022-05-18 22:17           ` Scott Branden
2022-05-18 22:17             ` Scott Branden
2022-05-18 22:17             ` Scott Branden
2022-05-18 22:17             ` Scott Branden
2022-05-18 22:17             ` Scott Branden
2022-05-19 12:19             ` Guilherme G. Piccoli
2022-05-19 12:19               ` Guilherme G. Piccoli
2022-05-19 12:19               ` Guilherme G. Piccoli
2022-05-19 12:19               ` Guilherme G. Piccoli
2022-05-19 12:19               ` Guilherme G. Piccoli
2022-05-19 19:20               ` Scott Branden
2022-05-19 19:20                 ` Scott Branden
2022-05-19 19:20                 ` Scott Branden
2022-05-19 19:20                 ` Scott Branden
2022-05-19 19:20                 ` Scott Branden
2022-05-23 14:56                 ` Guilherme G. Piccoli
2022-05-23 14:56                   ` Guilherme G. Piccoli
2022-05-23 14:56                   ` Guilherme G. Piccoli
2022-05-23 14:56                   ` Guilherme G. Piccoli
2022-05-24  8:04                   ` Petr Mladek
2022-05-24  8:04                     ` Petr Mladek
2022-05-24  8:04                     ` Petr Mladek
2022-05-24  8:04                     ` Petr Mladek
2022-05-24  8:04                     ` Petr Mladek
2022-05-18  7:58         ` Petr Mladek
2022-05-18  7:58           ` Petr Mladek
2022-05-18  7:58           ` Petr Mladek
2022-05-18  7:58           ` Petr Mladek
2022-05-18 13:16           ` Guilherme G. Piccoli
2022-05-18 13:16             ` Guilherme G. Piccoli
2022-05-18 13:16             ` Guilherme G. Piccoli
2022-05-18 13:16             ` Guilherme G. Piccoli
2022-05-18 13:16             ` Guilherme G. Piccoli
2022-05-19  7:03             ` Petr Mladek
2022-05-19  7:03               ` Petr Mladek
2022-05-19  7:03               ` Petr Mladek
2022-05-19  7:03               ` Petr Mladek
2022-05-19  7:03               ` Petr Mladek
2022-05-19 12:07               ` Guilherme G. Piccoli
2022-05-19 12:07                 ` Guilherme G. Piccoli
2022-05-19 12:07                 ` Guilherme G. Piccoli
2022-05-19 12:07                 ` Guilherme G. Piccoli
2022-05-19 12:07                 ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 20/30] panic: Add the panic informational " Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 23:49   ` Paul E. McKenney
2022-04-27 23:49     ` Paul E. McKenney
2022-04-27 23:49     ` Paul E. McKenney
2022-04-27 23:49     ` Paul E. McKenney
2022-04-27 23:49     ` Paul E. McKenney
2022-04-28  8:14   ` Suzuki K Poulose
2022-04-28  8:14     ` Suzuki K Poulose
2022-04-28  8:14     ` Suzuki K Poulose
2022-04-28  8:14     ` Suzuki K Poulose
2022-04-28  8:14     ` Suzuki K Poulose
2022-04-29 14:50     ` Guilherme G. Piccoli
2022-04-29 14:50       ` Guilherme G. Piccoli
2022-04-29 14:50       ` Guilherme G. Piccoli
2022-04-29 14:50       ` Guilherme G. Piccoli
2022-04-29 14:50       ` Guilherme G. Piccoli
2022-05-16 14:11   ` Petr Mladek
2022-05-16 14:11     ` Petr Mladek
2022-05-16 14:11     ` Petr Mladek
2022-05-16 14:11     ` Petr Mladek
2022-05-16 14:11     ` Petr Mladek
2022-05-16 14:28     ` Guilherme G. Piccoli
2022-05-16 14:28       ` Guilherme G. Piccoli
2022-05-16 14:28       ` Guilherme G. Piccoli
2022-05-16 14:28       ` Guilherme G. Piccoli
2022-05-16 14:28       ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 21/30] panic: Introduce the panic pre-reboot " Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-28 14:13   ` Alex Elder
2022-04-28 14:13     ` Alex Elder
2022-04-28 14:13     ` Alex Elder
2022-04-28 14:13     ` Alex Elder
2022-04-28 14:13     ` Alex Elder
2022-04-28 16:26   ` Corey Minyard
2022-04-28 16:26     ` Corey Minyard
2022-04-28 16:26     ` Corey Minyard
2022-04-28 16:26     ` Corey Minyard
2022-04-28 16:26     ` Corey Minyard
2022-04-29 15:18     ` Guilherme G. Piccoli
2022-04-29 15:18       ` Guilherme G. Piccoli
2022-04-29 15:18       ` Guilherme G. Piccoli
2022-04-29 15:18       ` Guilherme G. Piccoli
2022-04-29 15:18       ` Guilherme G. Piccoli
2022-04-29 16:04   ` Max Filippov
2022-04-29 16:04     ` Max Filippov
2022-04-29 16:04     ` Max Filippov
2022-04-29 16:04     ` Max Filippov
2022-04-29 16:04     ` Max Filippov
2022-04-29 19:34     ` Guilherme G. Piccoli
2022-04-29 19:34       ` Guilherme G. Piccoli
2022-04-29 19:34       ` Guilherme G. Piccoli
2022-04-29 19:34       ` Guilherme G. Piccoli
2022-04-29 19:34       ` Guilherme G. Piccoli
2022-05-16 14:33   ` Petr Mladek
2022-05-16 14:33     ` Petr Mladek
2022-05-16 14:33     ` Petr Mladek
2022-05-16 14:33     ` Petr Mladek
2022-05-16 14:33     ` Petr Mladek
2022-05-16 16:05     ` Guilherme G. Piccoli
2022-05-16 16:05       ` Guilherme G. Piccoli
2022-05-16 16:05       ` Guilherme G. Piccoli
2022-05-16 16:05       ` Guilherme G. Piccoli
2022-05-16 16:05       ` Guilherme G. Piccoli
2022-05-16 16:18       ` Luck, Tony
2022-05-16 16:18         ` Luck, Tony
2022-05-16 16:18         ` Luck, Tony
2022-05-16 16:18         ` Luck, Tony
2022-05-16 16:18         ` Luck, Tony
2022-05-16 16:33         ` Guilherme G. Piccoli
2022-05-16 16:33           ` Guilherme G. Piccoli
2022-05-16 16:33           ` Guilherme G. Piccoli
2022-05-16 16:33           ` Guilherme G. Piccoli
2022-05-16 16:33           ` Guilherme G. Piccoli
2022-05-17 14:11           ` Petr Mladek
2022-05-17 14:11             ` Petr Mladek via Openipmi-developer
2022-05-17 14:11             ` Petr Mladek
2022-05-17 14:11             ` Petr Mladek
2022-05-17 14:11             ` Petr Mladek
2022-05-17 16:45             ` Guilherme G. Piccoli
2022-05-17 16:45               ` Guilherme G. Piccoli
2022-05-17 16:45               ` Guilherme G. Piccoli
2022-05-17 16:45               ` Guilherme G. Piccoli
2022-05-17 16:45               ` Guilherme G. Piccoli
2022-05-17 17:02               ` Luck, Tony
2022-05-17 17:02                 ` Luck, Tony
2022-05-17 17:02                 ` Luck, Tony
2022-05-17 17:02                 ` Luck, Tony
2022-05-17 17:02                 ` Luck, Tony
2022-05-17 18:12                 ` Guilherme G. Piccoli
2022-05-17 18:12                   ` Guilherme G. Piccoli
2022-05-17 18:12                   ` Guilherme G. Piccoli
2022-05-17 18:12                   ` Guilherme G. Piccoli
2022-05-17 18:12                   ` Guilherme G. Piccoli
2022-05-17 19:07                   ` Luck, Tony
2022-05-17 19:07                     ` Luck, Tony
2022-05-17 19:07                     ` Luck, Tony
2022-05-17 19:07                     ` Luck, Tony
2022-05-17 19:07                     ` Luck, Tony
2022-04-27 22:49 ` [PATCH 22/30] panic: Introduce the panic post-reboot " Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-09 14:16   ` Guilherme G. Piccoli
2022-05-09 14:16     ` Guilherme G. Piccoli
2022-05-09 14:16     ` Guilherme G. Piccoli
2022-05-09 14:16     ` Guilherme G. Piccoli
2022-05-09 14:16     ` Guilherme G. Piccoli
2022-05-11 16:45     ` Heiko Carstens
2022-05-11 16:45       ` Heiko Carstens
2022-05-11 16:45       ` Heiko Carstens
2022-05-11 16:45       ` Heiko Carstens
2022-05-11 16:45       ` Heiko Carstens
2022-05-11 19:58       ` Guilherme G. Piccoli
2022-05-11 19:58         ` Guilherme G. Piccoli
2022-05-11 19:58         ` Guilherme G. Piccoli
2022-05-11 19:58         ` Guilherme G. Piccoli
2022-05-11 19:58         ` Guilherme G. Piccoli
2022-05-16 14:45   ` Petr Mladek
2022-05-16 14:45     ` Petr Mladek
2022-05-16 14:45     ` Petr Mladek
2022-05-16 14:45     ` Petr Mladek
2022-05-16 14:45     ` Petr Mladek
2022-05-16 16:08     ` Guilherme G. Piccoli
2022-05-16 16:08       ` Guilherme G. Piccoli
2022-05-16 16:08       ` Guilherme G. Piccoli
2022-05-16 16:08       ` Guilherme G. Piccoli
2022-05-16 16:08       ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 23/30] printk: kmsg_dump: Introduce helper to inform number of dumpers Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-10 17:40   ` Steven Rostedt
2022-05-10 17:40     ` Steven Rostedt
2022-05-10 17:40     ` Steven Rostedt
2022-05-10 17:40     ` Steven Rostedt
2022-05-10 17:40     ` Steven Rostedt
2022-05-11 20:03     ` Guilherme G. Piccoli
2022-05-11 20:03       ` Guilherme G. Piccoli
2022-05-11 20:03       ` Guilherme G. Piccoli
2022-05-11 20:03       ` Guilherme G. Piccoli
2022-05-11 20:03       ` Guilherme G. Piccoli
2022-05-16 14:50       ` Petr Mladek
2022-05-16 14:50         ` Petr Mladek
2022-05-16 14:50         ` Petr Mladek
2022-05-16 14:50         ` Petr Mladek
2022-05-16 14:50         ` Petr Mladek
2022-05-16 16:09         ` Guilherme G. Piccoli
2022-05-16 16:09           ` Guilherme G. Piccoli
2022-05-16 16:09           ` Guilherme G. Piccoli
2022-05-16 16:09           ` Guilherme G. Piccoli
2022-05-16 16:09           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 24/30] panic: Refactor the panic path Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-28  0:28   ` Randy Dunlap
2022-04-28  0:28     ` Randy Dunlap
2022-04-28  0:28     ` Randy Dunlap
2022-04-28  0:28     ` Randy Dunlap
2022-04-28  0:28     ` Randy Dunlap
2022-04-29 16:04     ` Guilherme G. Piccoli
2022-04-29 16:04       ` Guilherme G. Piccoli
2022-04-29 16:04       ` Guilherme G. Piccoli
2022-04-29 16:04       ` Guilherme G. Piccoli
2022-04-29 16:04       ` Guilherme G. Piccoli
2022-05-09 14:25       ` Guilherme G. Piccoli
2022-05-09 14:25         ` Guilherme G. Piccoli
2022-05-09 14:25         ` Guilherme G. Piccoli
2022-05-09 14:25         ` Guilherme G. Piccoli
2022-05-09 14:25         ` Guilherme G. Piccoli
2022-04-29 17:53   ` Michael Kelley (LINUX)
2022-04-29 17:53     ` Michael Kelley (LINUX)
2022-04-29 17:53     ` Michael Kelley
2022-04-29 17:53     ` Michael Kelley (LINUX)
2022-04-29 20:38     ` Guilherme G. Piccoli
2022-04-29 20:38       ` Guilherme G. Piccoli
2022-04-29 20:38       ` Guilherme G. Piccoli
2022-04-29 20:38       ` Guilherme G. Piccoli
2022-04-29 20:38       ` Guilherme G. Piccoli
2022-05-03 17:31       ` Michael Kelley (LINUX)
2022-05-03 17:31         ` Michael Kelley (LINUX)
2022-05-03 17:31         ` Michael Kelley
2022-05-03 17:31         ` Michael Kelley (LINUX)
2022-05-03 18:06         ` Guilherme G. Piccoli
2022-05-03 18:06           ` Guilherme G. Piccoli
2022-05-03 18:06           ` Guilherme G. Piccoli
2022-05-03 18:06           ` Guilherme G. Piccoli
2022-05-03 18:06           ` Guilherme G. Piccoli
2022-05-09 15:16   ` d.hatayama
2022-05-09 15:16     ` d.hatayama
2022-05-09 15:16     ` d.hatayama
2022-05-09 15:16     ` d.hatayama
2022-05-09 15:16     ` d.hatayama
2022-05-09 16:39     ` Guilherme G. Piccoli
2022-05-09 16:39       ` Guilherme G. Piccoli
2022-05-09 16:39       ` Guilherme G. Piccoli
2022-05-09 16:39       ` Guilherme G. Piccoli
2022-05-09 16:39       ` Guilherme G. Piccoli
2022-05-12 14:03   ` Petr Mladek
2022-05-12 14:03     ` Petr Mladek
2022-05-12 14:03     ` Petr Mladek
2022-05-12 14:03     ` Petr Mladek
2022-05-12 14:03     ` Petr Mladek
2022-05-15 22:47     ` Guilherme G. Piccoli
2022-05-15 22:47       ` Guilherme G. Piccoli
2022-05-15 22:47       ` Guilherme G. Piccoli
2022-05-15 22:47       ` Guilherme G. Piccoli
2022-05-15 22:47       ` Guilherme G. Piccoli
2022-05-16 10:21       ` Petr Mladek
2022-05-16 10:21         ` Petr Mladek
2022-05-16 10:21         ` Petr Mladek
2022-05-16 10:21         ` Petr Mladek
2022-05-16 10:21         ` Petr Mladek
2022-05-16 16:32         ` Guilherme G. Piccoli
2022-05-16 16:32           ` Guilherme G. Piccoli
2022-05-16 16:32           ` Guilherme G. Piccoli
2022-05-16 16:32           ` Guilherme G. Piccoli
2022-05-16 16:32           ` Guilherme G. Piccoli
2022-05-19 23:45       ` Baoquan He
2022-05-19 23:45         ` Baoquan He
2022-05-19 23:45         ` Baoquan He
2022-05-19 23:45         ` Baoquan He
2022-05-19 23:45         ` Baoquan He
2022-05-20 11:23         ` Guilherme G. Piccoli
2022-05-20 11:23           ` Guilherme G. Piccoli
2022-05-20 11:23           ` Guilherme G. Piccoli
2022-05-20 11:23           ` Guilherme G. Piccoli
2022-05-20 11:23           ` Guilherme G. Piccoli
2022-05-24  8:01           ` Petr Mladek
2022-05-24  8:01             ` Petr Mladek
2022-05-24  8:01             ` Petr Mladek
2022-05-24  8:01             ` Petr Mladek
2022-05-24  8:01             ` Petr Mladek
2022-05-24 10:18             ` Baoquan He
2022-05-24 10:18               ` Baoquan He
2022-05-24 10:18               ` Baoquan He
2022-05-24 10:18               ` Baoquan He
2022-05-24 10:18               ` Baoquan He
2022-05-24  8:32           ` Baoquan He
2022-05-24  8:32             ` Baoquan He
2022-05-24  8:32             ` Baoquan He
2022-05-24  8:32             ` Baoquan He
2022-05-24  8:32             ` Baoquan He
2022-05-24 14:44   ` Eric W. Biederman
2022-05-24 14:44     ` Eric W. Biederman
2022-05-24 14:44     ` Eric W. Biederman
2022-05-24 14:44     ` Eric W. Biederman
2022-05-24 14:44     ` Eric W. Biederman
2022-05-26 16:25     ` Guilherme G. Piccoli
2022-05-26 16:25       ` Guilherme G. Piccoli
2022-05-26 16:25       ` Guilherme G. Piccoli
2022-05-26 16:25       ` Guilherme G. Piccoli
2022-05-26 16:25       ` Guilherme G. Piccoli
2022-06-14 14:36       ` Petr Mladek
2022-06-14 14:36         ` Petr Mladek
2022-06-14 14:36         ` Petr Mladek
2022-06-14 14:36         ` Petr Mladek
2022-06-14 14:36         ` Petr Mladek
2022-06-15  9:36         ` Guilherme G. Piccoli
2022-06-15  9:36           ` Guilherme G. Piccoli
2022-06-15  9:36           ` Guilherme G. Piccoli
2022-06-15  9:36           ` Guilherme G. Piccoli
2022-06-15  9:36           ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 25/30] panic, printk: Add console flush parameter and convert panic_print to a notifier Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-16 14:56   ` Petr Mladek
2022-05-16 14:56     ` Petr Mladek
2022-05-16 14:56     ` Petr Mladek
2022-05-16 14:56     ` Petr Mladek
2022-05-16 14:56     ` Petr Mladek
2022-05-16 16:11     ` Guilherme G. Piccoli
2022-05-16 16:11       ` Guilherme G. Piccoli
2022-05-16 16:11       ` Guilherme G. Piccoli
2022-05-16 16:11       ` Guilherme G. Piccoli
2022-05-16 16:11       ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 26/30] Drivers: hv: Do not force all panic notifiers to execute before kdump Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 27/30] powerpc: " Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 28/30] panic: Unexport crash_kexec_post_notifiers Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 29/30] powerpc: ps3, pseries: Avoid duplicate call to kmsg_dump() on panic Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 30/30] um: Avoid duplicate call to kmsg_dump() Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-04-27 22:49   ` Guilherme G. Piccoli
2022-05-24 11:08 ` (subset) [PATCH 00/30] The panic notifiers refactor Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220427224924.592546-17-gpiccoli@igalia.com \
    --to=gpiccoli@igalia.com \
    --cc=Tianyu.Lan@microsoft.com \
    --cc=akpm@linux-foundation.org \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=coresight@lists.linaro.org \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=dyoung@redhat.com \
    --cc=fabiomirmar@gmail.com \
    --cc=feng.tang@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=haiyangz@microsoft.com \
    --cc=halves@canonical.com \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=jgross@suse.com \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=kernel-dev@igalia.com \
    --cc=kernel@gpiccoli.net \
    --cc=kexec@lists.infradead.org \
    --cc=kys@microsoft.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wei.liu@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.