From: Petr Mladek <pmladek@suse.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: akpm@linux-foundation.org, bhe@redhat.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com,
linuxppc-dev@lists.ozlabs.org, linux-alpha@vger.kernel.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, 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
Subject: Re: [PATCH 14/30] panic: Properly identify the panic event to the notifiers' callbacks
Date: Tue, 17 May 2022 15:11:10 +0200 [thread overview]
Message-ID: <YoOe7ifxfW8CEHdt@alley> (raw)
In-Reply-To: <244a412c-4589-28d1-bb77-d3648d4f0b12@igalia.com>
On Tue 2022-05-10 13:16:54, Guilherme G. Piccoli wrote:
> On 10/05/2022 12:16, Petr Mladek wrote:
> > [...]
> > Hmm, this looks like a hack. PANIC_UNUSED will never be used.
> > All notifiers will be always called with PANIC_NOTIFIER.
> >
> > The @val parameter is normally used when the same notifier_list
> > is used in different situations.
> >
> > But you are going to use it when the same notifier is used
> > in more lists. This is normally distinguished by the @nh
> > (atomic_notifier_head) parameter.
> >
> > IMHO, it is a bad idea. First, it would confuse people because
> > it does not follow the original design of the parameters.
> > Second, the related code must be touched anyway when
> > the notifier is moved into another list so it does not
> > help much.
> >
> > Or do I miss anything, please?
> >
> > Best Regards,
> > Petr
>
> Hi Petr, thanks for the review.
>
> I'm not strong attached to this patch, so we could drop it and refactor
> the code of next patches to use the @nh as identification - but
> personally, I feel this parameter could be used to identify the list
> that called such function, in other words, what is the event that
> triggered the callback. Some notifiers are even declared with this
> parameter called "ev", like the event that triggers the notifier.
>
>
> You mentioned 2 cases:
>
> (a) Same notifier_list used in different situations;
>
> (b) Same *notifier callback* used in different lists;
>
> Mine is case (b), right? Can you show me an example of case (a)?
There are many examples of case (a):
+ module_notify_list:
MODULE_STATE_LIVE, /* Normal state. */
MODULE_STATE_COMING, /* Full formed, running module_init. */
MODULE_STATE_GOING, /* Going away. */
MODULE_STATE_UNFORMED, /* Still setting it up. */
+ netdev_chain:
NETDEV_UP = 1, /* For now you can't veto a device up/down */
NETDEV_DOWN,
NETDEV_REBOOT, /* Tell a protocol stack a network interface
detected a hardware crash and restarted
- we can use this eg to kick tcp sessions
once done */
NETDEV_CHANGE, /* Notify device state change */
NETDEV_REGISTER,
NETDEV_UNREGISTER,
NETDEV_CHANGEMTU, /* notify after mtu change happened */
NETDEV_CHANGEADDR, /* notify after the address change */
NETDEV_PRE_CHANGEADDR, /* notify before the address change */
NETDEV_GOING_DOWN,
...
+ vt_notifier_list:
#define VT_ALLOCATE 0x0001 /* Console got allocated */
#define VT_DEALLOCATE 0x0002 /* Console will be deallocated */
#define VT_WRITE 0x0003 /* A char got output */
#define VT_UPDATE 0x0004 /* A bigger update occurred */
#define VT_PREWRITE 0x0005 /* A char is about to be written to the console */
+ die_chain:
DIE_OOPS = 1,
DIE_INT3,
DIE_DEBUG,
DIE_PANIC,
DIE_NMI,
DIE_DIE,
DIE_KERNELDEBUG,
...
These all call the same list/chain in different situations.
The situation is distinguished by @val.
> You can see in the following patches (or grep the kernel) that people are using
> this identification parameter to determine which kind of OOPS trigger
> the callback to condition the execution of the function to specific
> cases.
Could you please show me some existing code for case (b)?
I am not able to find any except in your patches.
Anyway, the solution in 16th patch is bad, definitely.
hv_die_panic_notify_crash() uses "val" to disinguish
both:
+ "panic_notifier_list" vs "die_chain"
+ die_val when callen via "die_chain"
The API around "die_chain" API is not aware of enum panic_notifier_val
and the API using "panic_notifier_list" is not aware of enum die_val.
As I said, it is mixing apples and oranges and it is error prone.
Best Regards,
Petr
next prev parent reply other threads:[~2022-05-17 13:12 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 [this message]
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)
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=YoOe7ifxfW8CEHdt@alley \
--to=pmladek@suse.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=dyoung@redhat.com \
--cc=fabiomirmar@gmail.com \
--cc=feng.tang@intel.com \
--cc=gpiccoli@igalia.com \
--cc=gregkh@linuxfoundation.org \
--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=linux-alpha@vger.kernel.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=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=sparclinux@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=vkuznets@redhat.com \
--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).