From: "Guilherme G. Piccoli" <gpiccoli@igalia.com> To: "bhe@redhat.com" <bhe@redhat.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:25:30 -0300 [thread overview] Message-ID: <788ab36d-ef65-4cc8-4edf-a46d2687d97e@igalia.com> (raw) In-Reply-To: <YiYQ/w6Hn5Zb67di@MiWiFi-R3L-srv> On 07/03/2022 11:04, bhe@redhat.com wrote: > [...] > Ah, sorry, I even didn't notice that. That's awesome if we can make use > of that. While I still have concerns: > Thanks, nice that you liked the idea. > 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? > While implementing that I will think of something, but if understood/remember correctly Hyper-V gonna be one of the first to run in the first notifier list proposed by Petr - so we might still use ordering by priority there, having Hyper-V being the first heh > 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. > This is a great point! How to do it? One idea is to have a special registering function for panic notifiers that checks for priority field missing, and good documentation is a good idea as well, always. But if you / others have other suggestions, let me know - appreciate that. Cheers, Guilherme
WARNING: multiple messages have this Message-ID (diff)
From: Guilherme G. Piccoli <gpiccoli@igalia.com> To: kexec@lists.infradead.org Subject: [PATCH V4] notifier/panic: Introduce panic_notifier_filter Date: Mon, 7 Mar 2022 11:25:30 -0300 [thread overview] Message-ID: <788ab36d-ef65-4cc8-4edf-a46d2687d97e@igalia.com> (raw) In-Reply-To: <YiYQ/w6Hn5Zb67di@MiWiFi-R3L-srv> On 07/03/2022 11:04, bhe at redhat.com wrote: > [...] > Ah, sorry, I even didn't notice that. That's awesome if we can make use > of that. While I still have concerns: > Thanks, nice that you liked the idea. > 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? > While implementing that I will think of something, but if understood/remember correctly Hyper-V gonna be one of the first to run in the first notifier list proposed by Petr - so we might still use ordering by priority there, having Hyper-V being the first heh > 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. > This is a great point! How to do it? One idea is to have a special registering function for panic notifiers that checks for priority field missing, and good documentation is a good idea as well, always. But if you / others have other suggestions, let me know - appreciate that. Cheers, Guilherme
next prev parent reply other threads:[~2022-03-07 14:25 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 (LINUX) 2022-02-10 17:26 ` Michael Kelley 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 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 [this message] 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=788ab36d-ef65-4cc8-4edf-a46d2687d97e@igalia.com \ --to=gpiccoli@igalia.com \ --cc=akpm@linux-foundation.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bhe@redhat.com \ --cc=corbet@lwn.net \ --cc=d.hatayama@fujitsu.com \ --cc=dyoung@redhat.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: linkBe 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.