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 22:04:47 +0800 [thread overview]
Message-ID: <YiYQ/w6Hn5Zb67di@MiWiFi-R3L-srv> (raw)
In-Reply-To: <e1033adc-46ff-5dbc-e739-1bf725b6fed0@igalia.com>
On 03/07/22 at 10:11am, Guilherme G. Piccoli wrote:
> On 07/03/2022 00:42, bhe@redhat.com wrote:
> > [...]
> >> 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)
> >
>
> Hi Baoquan, thanks for you consideration! In fact, the notifiers
> infrastructure already have a mechanism of ordering, my idea is to make
> use of that. It's not that different from the initcall system...
Ah, sorry, I even didn't notice that. That's awesome if we can make use
of that. While I still have concerns:
1) about those we have decided to take out from panic notifier list and
put before kdump, e.g the Hypver-V notifier, how will we do with it? Are
we going to handle them as we have discussed?
2) Combing and settling priority for all existing panic notifier looks
great, even though it will take some effort. How about the later newly
added one? How can we guarantee that those new notifiers are getting
appropriate priority to mark their order? Sometime we even don't know
a new panic notifier is added since code change may be made in any
component or driver.
>
> For instance, the code in the notifier register function checks for the
> priority field in the notifier block:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/notifier.c#n31
> .
>
> For example, the Xen panic notifier is one of the few blocks that make
> use of that, currently:
>
> static struct notifier_block xen_panic_block = {
> .notifier_call = xen_panic_event,
> .priority = INT_MIN
> };
>
> (see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/xen/enlighten.c#n286)
>
> In this case, xen_panic_event() will be the latest one to run. My idea
> is to make use of that in *all* panic notifiers, having a table/list on
> panic_notifier.h (defines or enum, I'll think about that when writing
> this part) so all notifiers are documented and the ordering is clear and
> enforced.
>
> Makes sense to you?
> Cheers,
>
>
> Guilherme
>
next prev parent reply other threads:[~2022-03-07 14:05 UTC|newest]
Thread overview: 34+ 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-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-16 13:11 ` Baoquan He
2022-01-17 12:59 ` Guilherme G. Piccoli
2022-01-20 15:14 ` Petr Mladek
2022-01-21 20:31 ` Guilherme G. Piccoli
2022-01-22 10:55 ` Baoquan He
2022-01-23 13:07 ` Masami Hiramatsu
2022-01-24 13:59 ` Baoquan He
2022-01-24 14:48 ` Guilherme G. Piccoli
2022-01-26 3:10 ` Baoquan He
2022-01-26 12:20 ` d.hatayama
2022-01-26 13:20 ` Petr Mladek
2022-01-30 8:50 ` Baoquan He
2022-01-24 11:43 ` d.hatayama
2022-01-24 14:15 ` Baoquan He
2022-01-25 11:50 ` d.hatayama
2022-01-25 12:34 ` Guilherme G. Piccoli
2022-01-25 13:06 ` d.hatayama
2022-01-27 17:16 ` Guilherme G. Piccoli
2022-01-28 13:38 ` Petr Mladek
2022-02-08 18:51 ` Guilherme G. Piccoli
2022-02-09 0:31 ` bhe
2022-02-10 16:39 ` Guilherme G. Piccoli
2022-02-10 17:26 ` Michael Kelley (LINUX)
2022-02-10 17:50 ` Guilherme G. Piccoli
2022-03-06 14:21 ` Guilherme G. Piccoli
2022-03-07 3:42 ` bhe
2022-03-07 13:11 ` Guilherme G. Piccoli
2022-03-07 14:04 ` bhe [this message]
2022-03-07 14:25 ` Guilherme G. Piccoli
2022-03-08 12:54 ` Petr Mladek
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=YiYQ/w6Hn5Zb67di@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corbet@lwn.net \
--cc=d.hatayama@fujitsu.com \
--cc=dyoung@redhat.com \
--cc=gpiccoli@igalia.com \
--cc=halves@canonical.com \
--cc=kernel@gpiccoli.net \
--cc=kexec@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=stern@rowland.harvard.edu \
--cc=vgoyal@redhat.com \
/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