From: "Michael Kelley (LINUX)" <mikelley@microsoft.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"bhe@redhat.com" <bhe@redhat.com>,
"pmladek@suse.com" <pmladek@suse.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"bcm-kernel-feedback-list@broadcom.com"
<bcm-kernel-feedback-list@broadcom.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-remoteproc@vger.kernel.org"
<linux-remoteproc@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"openipmi-developer@lists.sourceforge.net"
<openipmi-developer@lists.sourceforge.net>,
"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"x86@kernel.org" <x86@kernel.org>,
"kernel-dev@igalia.com" <kernel-dev@igalia.com>,
"kernel@gpiccoli.net" <kernel@gpiccoli.net>,
"halves@canonical.com" <halves@canonical.com>,
"fabiomirmar@gmail.com" <fabiomirmar@gmail.com>,
"alejandro.j.jimenez@oracle.com" <alejandro.j.jimenez@oracle.com>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"arnd@arndb.de" <arnd@arndb.de>, "bp@alien8.de" <bp@alien8.de>,
"corbet@lwn.net" <corbet@lwn.net>,
"d.hatayama@jp.fujitsu.com" <d.hatayama@jp.fujitsu.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"feng.tang@intel.com" <feng.tang@intel.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"hidehiro.kawai.ez@hitachi.com" <hidehiro.kawai.ez@hitachi.com>,
"jgross@suse.com" <jgross@suse.com>,
"john.ogness@linutronix.de" <john.ogness@linutronix.de>,
"keescook@chromium.org" <keescook@chromium.org>,
"luto@kernel.org" <luto@kernel.org>,
"mhiramat@kernel.org" <mhiramat@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"paulmck@kernel.org" <paulmck@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"senozhatsky@chromium.org" <senozhatsky@chromium.org>,
"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"vgoyal@redhat.com" <vgoyal@redhat.com>,
vkuznets <vkuznets@redhat.com>,
"will@kernel.org" <will@kernel.org>,
Andrea Parri <parri.andrea@gmail.com>,
Dexuan Cui <decui@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
KY Srinivasan <kys@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Tianyu Lan <Tianyu.Lan@microsoft.com>,
Wei Liu <wei.liu@kernel.org>
Subject: RE: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers
Date: Tue, 3 May 2022 18:13:52 +0000 [thread overview]
Message-ID: <PH0PR21MB3025A46643EEDA6B14AC1ECED7C09@PH0PR21MB3025.namprd21.prod.outlook.com> (raw)
In-Reply-To: <2787b476-6366-1c83-db80-0393da417497@igalia.com>
From: Guilherme G. Piccoli <gpiccoli@igalia.com> Sent: Friday, April 29, 2022 3:35 PM
>
> Hi Michael, first of all thanks for the great review, much appreciated.
> Some comments inline below:
>
> On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> > [...]
> >> 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.
> >
> > While the last sentence is true for Hyper-V on x86/x64, it's not true for
> > Hyper-V on ARM64. x86/x64 has the 'machine_ops' data structure
> > with the ability to provide a custom crash_shutdown() function, which
> > Hyper-V does in the form of hv_machine_crash_shutdown(). But ARM64
> > has no mechanism to provide such a custom function that will eventually
> > do the needed vmbus_initiate_unload() before running kdump.
> >
> > I'm not immediately sure what the best solution is for ARM64. At this
> > point, I'm just pointing out the problem and will think about the tradeoffs
> > for various possible solutions. Please do the same yourself. :-)
> >
>
> Oh, you're totally right! I just assumed ARM64 would the the same, my
> bad. Just to propose some alternatives, so you/others can also discuss
> here and we can reach a consensus about the trade-offs:
>
> (a) We could forget about this change, and always do the clean-up here,
> not relying in machine_crash_shutdown().
> Pro: really simple, behaves the same as it is doing currently.
> Con: less elegant/concise, doesn't allow arm64 customization.
>
> (b) Add a way to allow ARM64 customization of shutdown crash handler.
> Pro: matches x86, more customizable, improves arm64 arch code.
> Con: A tad more complex.
>
> Also, a question that came-up: if ARM64 has no way of calling special
> crash shutdown handler, how can you execute hv_stimer_cleanup() and
> hv_synic_disable_regs() there? Or are they not required in ARM64?
>
My suggestion is to do (a) for now. I suspect (b) could be a more
extended discussion and I wouldn't want your patch set to get held
up on that discussion. I don't know what the sense of the ARM64
maintainers would be toward (b). They have tried to avoid picking
up code warts like have accumulated on the x86/x64 side over the
years, and I agree with that effort. But as more and varied
hypervisors become available for ARM64, it seems like a framework
for supporting a custom shutdown handler may become necessary.
But that could take a little time.
You are right about hv_stimer_cleanup() and hv_synic_disable_regs().
We are not running these when a panic occurs on ARM64, and we
should be, though the risk is small. We will pursue (b) and add
these additional cleanups as part of that. But again, I would suggest
doing (a) for now, and we will switch back to your solution once
(b) is in place.
>
> >>
> >> (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.
> >
> > Patch 21 of this set puts the Hyper-V FB panic notifier on the pre_reboot
> > notifier list, which means it won't execute before the VMbus connection
> > unload in the case of kdump. This notifier is making sure that Hyper-V
> > is notified about the last updates made to the frame buffer before the
> > panic, so maybe it needs to be put on the hypervisor notifier list. It
> > sends a message to Hyper-V over its existing VMbus channel, but it
> > does not wait for a reply. It does, however, obtain a spin lock on the
> > ring buffer used to communicate with Hyper-V. Unless someone has
> > a better suggestion, I'm inclined to take the risk of blocking on that
> > spin lock.
>
> The logic behind that was: when kdump is set, we'd skip the vmbus
> disconnect on notifiers, deferring that to crash_shutdown(), logic this
> one refuted in the above discussion on ARM64 (one more Pro argument to
> the idea of refactoring aarch64 code to allow a custom crash shutdown
> handler heh). But you're right, for the default level 2, we skip the
> pre_reboot notifiers on kdump, effectively skipping this notifier.
>
> Some ideas of what we can do here:
>
> I) we could change the framebuffer notifier to rely on trylocks, instead
> of risking a lockup scenario, and with that, we can execute it before
> the vmbus disconnect in the hypervisor list;
I think we have to do this approach for now.
>
> II) we ignore the hypervisor notifier in case of kdump _by default_, and
> if the users don't want that, they can always set the panic notifier
> level to 4 and run all notifiers prior to kdump; would that be terrible
> you think? Kdump users might don't care about the framebuffer...
>
> III) we go with approach (b) above and refactor arm64 code to allow the
> custom crash handler on kdump time, then [with point (I) above] the
> logic proposed in this series is still valid - seems more and more the
> most correct/complete solution.
But even when/if we get approach (b) implemented, having the
framebuffer notifier on the pre_reboot list is still too late with the
default of panic_notifier_level = 2. The kdump path will reset the
VMbus connection and then the framebuffer notifier won't work.
>
> In any case, I guess we should avoid workarounds if possible and do the
> things the best way we can, to encompass all (or almost all) the
> possible scenarios and don't force things on users (like enforcing panic
> notifier level 4 for Hyper-V or something like this...)
>
> More feedback from you / Hyper-V folks is pretty welcome about this.
>
>
> >
> >> [...]
> > The "Fixes:" tags imply that these changes should be backported to older
> > longterm kernel versions, which I don't think is the case. There is a
> > dependency on Patch 14 of your series where PANIC_NOTIFIER is
> > introduced.
> >
>
> Oh, this was more related with archeology of the kernel. When I'm
> investigating stuff, I really want to understand why code was added and
> that usually require some time git blaming stuff, so having that pronto
> in the commit message is a bonus.
>
> But of course we don't need to use the Fixes tag for that, easy to only
> mention it in the text. A secondary benefit by using this tag is to
> indicate this is a _real fix_ to some code, and not an improvement, but
> as you say, I agree we shouldn't backport it to previous releases having
> or not the Fixes tag (AFAIK it's not mandatory to backport stuff with
> Fixes tag).
>
>
> >> [...]
> >> + * intrincated is the relation of this notifier with Hyper-V framebuffer
> >
> > s/intrincated/intricate/
>
> Thanks, fixed in V2!
>
>
> >
> >> [...]
> >> +static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
> >> void *args)
> >> +{
> >> + if (!kexec_crash_loaded())
> >
> > I'm not clear on the purpose of this condition. I think it means
> > we will skip the vmbus_initiate_unload() if a panic occurs in the
> > kdump kernel. Is there a reason a panic in the kdump kernel
> > should be treated differently? Or am I misunderstanding?
>
> This is really related with the point discussed in the top of this
> response - I assumed both ARM64/x86_64 would behave the same and
> disconnect the vmbus through the custom crash handler when kdump is set,
> so worth skipping it here in the notifier. But that's not true for ARM64
> as you pointed, so this guard against kexec is really part of the
> decision/discussion on what to do with ARM64 heh
But note that vmbus_initiate_unload() already has a guard built-in.
If the intent of this test is just as a guard against running twice,
then it isn't needed.
>
> Cheers!
next prev parent reply other threads:[~2022-05-03 18:14 UTC|newest]
Thread overview: 183+ 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 ` [PATCH 01/30] x86/crash,reboot: Avoid re-disabling VMX in all CPUs on crash/restart Guilherme G. Piccoli
2022-05-09 12:32 ` Guilherme G. Piccoli
2022-05-09 15:52 ` Sean Christopherson
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-29 16:26 ` Michael Kelley (LINUX)
2022-04-29 18:20 ` Marc Zyngier
2022-04-29 21:38 ` Guilherme G. Piccoli
2022-04-29 21:45 ` Russell King (Oracle)
2022-04-29 21:56 ` Guilherme G. Piccoli
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 ` [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path Guilherme G. Piccoli
2022-05-03 18:03 ` Evan Green
2022-05-03 19:12 ` Guilherme G. Piccoli
2022-05-03 21:56 ` Evan Green
2022-05-04 12:45 ` Guilherme G. Piccoli
2022-05-10 11:38 ` Petr Mladek
2022-05-10 13:04 ` Guilherme G. Piccoli
2022-05-10 17:20 ` Steven Rostedt
2022-05-10 19:40 ` John Ogness
2022-05-11 11:13 ` Petr Mladek
2022-04-27 22:48 ` [PATCH 05/30] misc/pvpanic: " Guilherme G. Piccoli
2022-05-10 12:14 ` Petr Mladek
2022-05-10 13:00 ` Guilherme G. Piccoli
2022-05-17 10:58 ` Petr Mladek
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-05-02 15:38 ` Florian Fainelli
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-05-04 20:32 ` Thomas Bogendoerfer
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-05-05 18:55 ` Hari Bathini
2022-05-05 19:28 ` Guilherme G. Piccoli
2022-05-09 12:50 ` Guilherme G. Piccoli
2022-05-10 13:53 ` Michael Ellerman
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-28 8:11 ` Suzuki K Poulose
2022-04-29 14:01 ` Guilherme G. Piccoli
2022-05-09 13:09 ` Guilherme G. Piccoli
2022-05-09 16:14 ` Suzuki K Poulose
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-05-09 14:13 ` Guilherme G. Piccoli
2022-05-10 14:16 ` Petr Mladek
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-28 8:30 ` Johannes Berg
2022-04-29 15:46 ` Guilherme G. Piccoli
2022-05-10 14:28 ` Petr Mladek
2022-05-11 20:22 ` Guilherme G. Piccoli
2022-05-13 14:44 ` Johannes Berg
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-28 16:55 ` Helge Deller
2022-04-29 14:34 ` 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-29 18:46 ` Heiko Carstens
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-05-10 15:16 ` Petr Mladek
2022-05-10 16:16 ` Guilherme G. Piccoli
2022-05-17 13:11 ` Petr Mladek
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-05-02 15:38 ` Florian Fainelli
2022-05-02 15:50 ` Guilherme G. Piccoli
2022-05-10 15:28 ` Petr Mladek
2022-05-17 15:32 ` Guilherme G. Piccoli
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-29 17:16 ` Michael Kelley (LINUX)
2022-04-29 22:35 ` Guilherme G. Piccoli
2022-05-03 18:13 ` Michael Kelley (LINUX) [this message]
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-29 9:22 ` Sergei Shtylyov
2022-04-29 13:23 ` Steven Rostedt
2022-04-29 13:46 ` Guilherme G. Piccoli
2022-04-29 13:56 ` Steven Rostedt
2022-04-29 14:44 ` Guilherme G. Piccoli
2022-05-11 11:45 ` Petr Mladek
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-28 1:01 ` Xiaoming Ni
2022-04-29 19:38 ` Guilherme G. Piccoli
2022-05-10 17:29 ` Steven Rostedt
2022-05-16 16:14 ` Guilherme G. Piccoli
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-29 17:30 ` Michael Kelley (LINUX)
2022-04-29 18:04 ` Guilherme G. Piccoli
2022-05-03 17:44 ` Michael Kelley (LINUX)
2022-05-03 17:56 ` Guilherme G. Piccoli
2022-05-16 14:01 ` Petr Mladek
2022-05-16 15:06 ` Guilherme G. Piccoli
2022-05-16 16:02 ` Evan Green
2022-05-17 13:28 ` Petr Mladek
2022-05-17 16:37 ` Guilherme G. Piccoli
2022-05-18 7:33 ` Petr Mladek
2022-05-18 13:24 ` Guilherme G. Piccoli
2022-05-17 13:57 ` Petr Mladek
2022-05-17 16:42 ` Guilherme G. Piccoli
2022-05-18 7:38 ` Petr Mladek
2022-05-18 13:09 ` Guilherme G. Piccoli
2022-05-18 22:17 ` Scott Branden
2022-05-19 12:19 ` Guilherme G. Piccoli
2022-05-19 19:20 ` Scott Branden
2022-05-23 14:56 ` Guilherme G. Piccoli
2022-05-24 8:04 ` Petr Mladek
2022-05-18 7:58 ` Petr Mladek
2022-05-18 13:16 ` Guilherme G. Piccoli
2022-05-19 7:03 ` Petr Mladek
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 23:49 ` Paul E. McKenney
2022-04-28 8:14 ` Suzuki K Poulose
2022-04-29 14:50 ` Guilherme G. Piccoli
2022-05-16 14:11 ` Petr Mladek
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-28 14:13 ` Alex Elder
2022-04-28 16:26 ` Corey Minyard
2022-04-29 15:18 ` Guilherme G. Piccoli
2022-04-29 16:04 ` Max Filippov
2022-04-29 19:34 ` Guilherme G. Piccoli
2022-05-16 14:33 ` Petr Mladek
2022-05-16 16:05 ` Guilherme G. Piccoli
2022-05-16 16:18 ` Luck, Tony
2022-05-16 16:33 ` Guilherme G. Piccoli
2022-05-17 14:11 ` Petr Mladek
2022-05-17 16:45 ` Guilherme G. Piccoli
2022-05-17 17:02 ` Luck, Tony
2022-05-17 18:12 ` Guilherme G. Piccoli
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-05-09 14:16 ` Guilherme G. Piccoli
2022-05-11 16:45 ` Heiko Carstens
2022-05-11 19:58 ` Guilherme G. Piccoli
2022-05-16 14:45 ` Petr Mladek
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-05-10 17:40 ` Steven Rostedt
2022-05-11 20:03 ` Guilherme G. Piccoli
2022-05-16 14:50 ` Petr Mladek
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-28 0:28 ` Randy Dunlap
2022-04-29 16:04 ` Guilherme G. Piccoli
2022-05-09 14:25 ` Guilherme G. Piccoli
2022-04-29 17:53 ` Michael Kelley (LINUX)
2022-04-29 20:38 ` Guilherme G. Piccoli
2022-05-03 17:31 ` Michael Kelley (LINUX)
2022-05-03 18:06 ` Guilherme G. Piccoli
2022-05-09 15:16 ` d.hatayama
2022-05-09 16:39 ` Guilherme G. Piccoli
2022-05-12 14:03 ` Petr Mladek
2022-05-15 22:47 ` Guilherme G. Piccoli
2022-05-16 10:21 ` Petr Mladek
2022-05-16 16:32 ` Guilherme G. Piccoli
2022-05-19 23:45 ` Baoquan He
2022-05-20 11:23 ` Guilherme G. Piccoli
2022-05-24 8:01 ` Petr Mladek
2022-05-24 10:18 ` Baoquan He
2022-05-24 8:32 ` Baoquan He
2022-05-24 14:44 ` Eric W. Biederman
2022-05-26 16:25 ` Guilherme G. Piccoli
2022-06-14 14:36 ` Petr Mladek
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-05-16 14:56 ` Petr Mladek
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 ` [PATCH 27/30] powerpc: " 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 ` [PATCH 29/30] powerpc: ps3, pseries: Avoid duplicate call to kmsg_dump() on panic Guilherme G. Piccoli
2022-04-27 22:49 ` [PATCH 30/30] um: Avoid duplicate call to kmsg_dump() Guilherme G. Piccoli
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=PH0PR21MB3025A46643EEDA6B14AC1ECED7C09@PH0PR21MB3025.namprd21.prod.outlook.com \
--to=mikelley@microsoft.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=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=gpiccoli@igalia.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).