From: bhe@redhat.com <bhe@redhat.com>
To: kexec@lists.infradead.org
Subject: [PATCH V4] notifier/panic: Introduce panic_notifier_filter
Date: Mon, 7 Mar 2022 11:42:21 +0800 [thread overview]
Message-ID: <YiV/HbXftVF2iAvU@MiWiFi-R3L-srv> (raw)
In-Reply-To: <73011b6f-084b-43f5-cc01-1818a8a57e56@igalia.com>
On 03/06/22 at 11:21am, Guilherme G. Piccoli wrote:
> On 28/01/2022 10:38, Petr Mladek wrote:
> > [...]
> > I think about the following solution:
> >
> > + split the notifiers into three lists:
> >
> > + info: stop watchdogs, provide extra info
> > + hypervisor: poke hypervisor
> > + reboot: actions needed only when crash dump did not happen
> >
> > + allow to call hypervisor notifiers before or after kdump
> >
> > + stop CPUs before kdump when either hypervisor notifiers or
> > kmsg_dump is enabled
> >
> > Note that it still allows to call kdump as the first action when
> > hypervisor notifiers are called after kdump and no kmsg dumper
> > is registered.
> >
> >
> > void panic(void)
> > {
> > [...]
> >
> > if (crash_kexec_post_hypervisor || panic_print || enabled_kmsg_dump()) {
> > /*
> > * Stop CPUs when some extra action is required before
> > * crash dump. We will need architecture dependent extra
> > * works in addition to stopping other CPUs.
> > */
> > crash_smp_send_stop();
> > cpus_stopped = true;
> > }
> >
> > if (crash_kexec_post_hypervisor) {
> > /* Tell hypervisor about the panic */
> > atomic_notifier_call_chain(&panic_hypervisor_notifier_list, 0, buf);
> > }
> >
> > if (enabled_kmsg_dump) {
> > /*
> > * Print extra info by notifiers.
> > * Prevent rumors, for example, by stopping watchdogs.
> > */
> > atomic_notifier_call_chain(&panic_info_notifier_list, 0, buf);
> > }
> >
> > /* Optional extra info */
> > panic_printk_sys_info();
> >
> > /* No dumper by default */
> > kmsg_dump();
> >
> > /* Used only when crash kernel loaded */
> > __crash_kexec(NULL);
> >
> > if (!cpus_stopped) {
> > /*
> > * Note smp_send_stop is the usual smp shutdown function, which
> > * unfortunately means it may not be hardened to work in a
> > * panic situation.
> > */
> > smp_send_stop();
> > }
> >
> > if (!crash_kexec_post_hypervisor) {
> > /* Tell hypervisor about the panic */
> > atomic_notifier_call_chain(&panic_hypervisor_notifier_list, 0, buf);
> > }
> >
> > if (!enabled_kmsg_dump) {
> > /*
> > * Print extra info by notifiers.
> > * Prevent rumors, for example, by stopping watchdogs.
> > */
> > atomic_notifier_call_chain(&panic_info_notifier_list, 0, buf);
> > }
> >
> > /*
> > * Help to reboot a safe way.
> > */
> > atomic_notifier_call_chain(&panic_reboot_notifier_list, 0, buf);
> >
> > [...]
> > }
> >
> > Any opinion?
> > Do the notifier list names make sense?
> >
> > Best Regards,
> > Petr
>
>
> Hi folks, I'm working on this now, and while looking into it I've
> noticed that we have the concept of "priority" in the notifiers list.
> Basically, you can order the calls the way it fits best, priority is an
> integer and must the set in the moment of registration, it's up to the
> users of the notifiers to set it and enforce the ordering.
>
> So what I'm thinking is: currently, only 3 or 4 panic notifiers make use
> of that. What if, since we're re-working this, we add a priority for
> *all* notifiers and enforce its usage? This way we guarantee
> consistency, it'd make debug easier and maybe even more important:
> having all the notifiers and their priorities in a list present in the
> header file would be great documentation about all the existing
> notifiers and how they are called - today this information is quite
> obscure and requires lots of code grepping!
>
> Let me know your thoughts Petr / Baoquan - it would add slightly more
> code / complexity, but in my opinion the payback is very good.
> Cheers,
The ideal situation is each panic notifier has an order or index to
indicate its priority. Wondering how to make it. What I think of is
copying initcall. We have several priorities, at the same priority,
execution sequence is not important. Not sure if I get your point.
~~~~~~~
#define core_initcall(fn) __define_initcall(fn, 1)
#define core_initcall_sync(fn) __define_initcall(fn, 1s)
......
#define late_initcall(fn) __define_initcall(fn, 7)
#define late_initcall_sync(fn) __define_initcall(fn, 7s)
WARNING: multiple messages have this Message-ID (diff)
From: "bhe@redhat.com" <bhe@redhat.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: Petr Mladek <pmladek@suse.com>,
"d.hatayama@fujitsu.com" <d.hatayama@fujitsu.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"vgoyal@redhat.com" <vgoyal@redhat.com>,
"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"halves@canonical.com" <halves@canonical.com>,
"kernel@gpiccoli.net" <kernel@gpiccoli.net>
Subject: Re: [PATCH V4] notifier/panic: Introduce panic_notifier_filter
Date: Mon, 7 Mar 2022 11:42:21 +0800 [thread overview]
Message-ID: <YiV/HbXftVF2iAvU@MiWiFi-R3L-srv> (raw)
In-Reply-To: <73011b6f-084b-43f5-cc01-1818a8a57e56@igalia.com>
On 03/06/22 at 11:21am, Guilherme G. Piccoli wrote:
> On 28/01/2022 10:38, Petr Mladek wrote:
> > [...]
> > I think about the following solution:
> >
> > + split the notifiers into three lists:
> >
> > + info: stop watchdogs, provide extra info
> > + hypervisor: poke hypervisor
> > + reboot: actions needed only when crash dump did not happen
> >
> > + allow to call hypervisor notifiers before or after kdump
> >
> > + stop CPUs before kdump when either hypervisor notifiers or
> > kmsg_dump is enabled
> >
> > Note that it still allows to call kdump as the first action when
> > hypervisor notifiers are called after kdump and no kmsg dumper
> > is registered.
> >
> >
> > void panic(void)
> > {
> > [...]
> >
> > if (crash_kexec_post_hypervisor || panic_print || enabled_kmsg_dump()) {
> > /*
> > * Stop CPUs when some extra action is required before
> > * crash dump. We will need architecture dependent extra
> > * works in addition to stopping other CPUs.
> > */
> > crash_smp_send_stop();
> > cpus_stopped = true;
> > }
> >
> > if (crash_kexec_post_hypervisor) {
> > /* Tell hypervisor about the panic */
> > atomic_notifier_call_chain(&panic_hypervisor_notifier_list, 0, buf);
> > }
> >
> > if (enabled_kmsg_dump) {
> > /*
> > * Print extra info by notifiers.
> > * Prevent rumors, for example, by stopping watchdogs.
> > */
> > atomic_notifier_call_chain(&panic_info_notifier_list, 0, buf);
> > }
> >
> > /* Optional extra info */
> > panic_printk_sys_info();
> >
> > /* No dumper by default */
> > kmsg_dump();
> >
> > /* Used only when crash kernel loaded */
> > __crash_kexec(NULL);
> >
> > if (!cpus_stopped) {
> > /*
> > * Note smp_send_stop is the usual smp shutdown function, which
> > * unfortunately means it may not be hardened to work in a
> > * panic situation.
> > */
> > smp_send_stop();
> > }
> >
> > if (!crash_kexec_post_hypervisor) {
> > /* Tell hypervisor about the panic */
> > atomic_notifier_call_chain(&panic_hypervisor_notifier_list, 0, buf);
> > }
> >
> > if (!enabled_kmsg_dump) {
> > /*
> > * Print extra info by notifiers.
> > * Prevent rumors, for example, by stopping watchdogs.
> > */
> > atomic_notifier_call_chain(&panic_info_notifier_list, 0, buf);
> > }
> >
> > /*
> > * Help to reboot a safe way.
> > */
> > atomic_notifier_call_chain(&panic_reboot_notifier_list, 0, buf);
> >
> > [...]
> > }
> >
> > Any opinion?
> > Do the notifier list names make sense?
> >
> > Best Regards,
> > Petr
>
>
> Hi folks, I'm working on this now, and while looking into it I've
> noticed that we have the concept of "priority" in the notifiers list.
> Basically, you can order the calls the way it fits best, priority is an
> integer and must the set in the moment of registration, it's up to the
> users of the notifiers to set it and enforce the ordering.
>
> So what I'm thinking is: currently, only 3 or 4 panic notifiers make use
> of that. What if, since we're re-working this, we add a priority for
> *all* notifiers and enforce its usage? This way we guarantee
> consistency, it'd make debug easier and maybe even more important:
> having all the notifiers and their priorities in a list present in the
> header file would be great documentation about all the existing
> notifiers and how they are called - today this information is quite
> obscure and requires lots of code grepping!
>
> Let me know your thoughts Petr / Baoquan - it would add slightly more
> code / complexity, but in my opinion the payback is very good.
> Cheers,
The ideal situation is each panic notifier has an order or index to
indicate its priority. Wondering how to make it. What I think of is
copying initcall. We have several priorities, at the same priority,
execution sequence is not important. Not sure if I get your point.
~~~~~~~
#define core_initcall(fn) __define_initcall(fn, 1)
#define core_initcall_sync(fn) __define_initcall(fn, 1s)
......
#define late_initcall(fn) __define_initcall(fn, 7)
#define late_initcall_sync(fn) __define_initcall(fn, 7s)
next prev parent reply other threads:[~2022-03-07 3:42 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 15:34 [PATCH V4] notifier/panic: Introduce panic_notifier_filter Guilherme G. Piccoli
2022-01-08 15:34 ` Guilherme G. Piccoli
2022-01-14 19:03 ` Guilherme G. Piccoli
2022-01-14 19:03 ` Guilherme G. Piccoli
[not found] ` <CALu+AoR+GrCpf0gqsx_XYETBGUAfRyP+SPNarK179hT7iQmCqQ@mail.gmail.com>
2022-01-18 13:22 ` Guilherme G. Piccoli
2022-01-18 13:22 ` Guilherme G. Piccoli
2022-01-16 13:11 ` Baoquan He
2022-01-16 13:11 ` Baoquan He
2022-01-17 12:59 ` Guilherme G. Piccoli
2022-01-17 12:59 ` Guilherme G. Piccoli
2022-01-20 15:14 ` Petr Mladek
2022-01-20 15:14 ` Petr Mladek
2022-01-21 20:31 ` Guilherme G. Piccoli
2022-01-21 20:31 ` Guilherme G. Piccoli
2022-01-22 10:55 ` Baoquan He
2022-01-22 10:55 ` Baoquan He
2022-01-23 13:07 ` Masami Hiramatsu
2022-01-23 13:07 ` Masami Hiramatsu
2022-01-24 13:59 ` Baoquan He
2022-01-24 13:59 ` Baoquan He
2022-01-24 14:48 ` Guilherme G. Piccoli
2022-01-24 14:48 ` Guilherme G. Piccoli
2022-01-26 3:10 ` Baoquan He
2022-01-26 3:10 ` Baoquan He
2022-01-26 12:20 ` d.hatayama
2022-01-26 12:20 ` d.hatayama
2022-01-26 13:20 ` Petr Mladek
2022-01-26 13:20 ` Petr Mladek
2022-01-30 8:50 ` Baoquan He
2022-01-30 8:50 ` Baoquan He
2022-01-24 11:43 ` d.hatayama
2022-01-24 11:43 ` d.hatayama
2022-01-24 14:15 ` Baoquan He
2022-01-24 14:15 ` Baoquan He
2022-01-25 11:50 ` d.hatayama
2022-01-25 11:50 ` d.hatayama
2022-01-25 12:34 ` Guilherme G. Piccoli
2022-01-25 12:34 ` Guilherme G. Piccoli
2022-01-25 13:06 ` d.hatayama
2022-01-25 13:06 ` d.hatayama
2022-01-27 17:16 ` Guilherme G. Piccoli
2022-01-27 17:16 ` Guilherme G. Piccoli
2022-01-28 13:38 ` Petr Mladek
2022-01-28 13:38 ` Petr Mladek
2022-02-08 18:51 ` Guilherme G. Piccoli
2022-02-08 18:51 ` Guilherme G. Piccoli
2022-02-09 0:31 ` bhe
2022-02-09 0:31 ` bhe
2022-02-10 16:39 ` Guilherme G. Piccoli
2022-02-10 16:39 ` Guilherme G. Piccoli
2022-02-10 17:26 ` Michael Kelley
2022-02-10 17:26 ` Michael Kelley (LINUX)
2022-02-10 17:50 ` Guilherme G. Piccoli
2022-02-10 17:50 ` Guilherme G. Piccoli
2022-03-06 14:21 ` Guilherme G. Piccoli
2022-03-06 14:21 ` Guilherme G. Piccoli
2022-03-07 3:42 ` bhe [this message]
2022-03-07 3:42 ` bhe
2022-03-07 13:11 ` Guilherme G. Piccoli
2022-03-07 13:11 ` Guilherme G. Piccoli
2022-03-07 14:04 ` bhe
2022-03-07 14:04 ` bhe
2022-03-07 14:25 ` Guilherme G. Piccoli
2022-03-07 14:25 ` Guilherme G. Piccoli
2022-03-08 12:54 ` Petr Mladek
2022-03-08 12:54 ` Petr Mladek
2022-03-08 13:04 ` Guilherme G. Piccoli
2022-03-08 13:04 ` 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=YiV/HbXftVF2iAvU@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=kexec@lists.infradead.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.