From: Petr Mladek <pmladek@suse.com>
To: Jinchao Wang <wangjinchao600@gmail.com>
Cc: "Sravan Kumar Gundu" <sravankumarlpu@gmail.com>,
linux-fbdev@vger.kernel.org, "Kees Cook" <kees@kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
"Yunhui Cui" <cuiyunhui@bytedance.com>,
"Yicong Yang" <yangyicong@hisilicon.com>,
"Zsolt Kajtar" <soci@c64.rulez.org>,
linux-hardening@vger.kernel.org, "Ingo Molnar" <mingo@kernel.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Max Kellermann" <max.kellermann@ionos.com>,
"John Ogness" <john.ogness@linutronix.de>,
"Baoquan He" <bhe@redhat.com>,
"Sergey Senozhatsky" <senozhatsky@chromium.org>,
"Helge Deller" <deller@gmx.de>,
"Joel Granados" <joel.granados@kernel.org>,
"Thorsten Blum" <thorsten.blum@linux.dev>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Dave Young" <dyoung@redhat.com>,
"Vivek Goyal" <vgoyal@redhat.com>,
"Nam Cao" <namcao@linutronix.de>,
"Qianqiang Liu" <qianqiang.liu@163.com>,
"Yury Norov" <yury.norov@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
dri-devel@lists.freedesktop.org,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Sohil Mehta" <sohil.mehta@intel.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Luo Gengkun" <luogengkun@huaweicloud.com>,
"Feng Tang" <feng.tang@linux.alibaba.com>,
"Shixiong Ou" <oushixiong@kylinos.cn>,
"Anna Schumaker" <anna.schumaker@oracle.com>,
"Tony Luck" <tony.luck@intel.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
kexec@lists.infradead.org,
"Douglas Anderson" <dianders@chromium.org>,
"Li Huafei" <lihuafei1@huawei.com>,
linux-kernel@vger.kernel.org,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Tejun Heo" <tj@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 1/9] panic: Introduce helper functions for panic state
Date: Tue, 16 Sep 2025 11:57:11 +0200 [thread overview]
Message-ID: <aMk0d5JO_4YECYGY@pathway.suse.cz> (raw)
In-Reply-To: <20250825022947.1596226-2-wangjinchao600@gmail.com>
On Mon 2025-08-25 10:29:29, Jinchao Wang wrote:
> This patch introduces four new helper functions to abstract the
> management of the panic_cpu variable. These functions will be used in
> subsequent patches to refactor existing code.
>
> The direct use of panic_cpu can be error-prone and ambiguous, as it
> requires manual checks to determine which CPU is handling the panic.
> The new helpers clarify intent:
>
> panic_try_start():
> Atomically sets the current CPU as the panicking CPU.
>
> panic_reset():
> Reset panic_cpu to PANIC_CPU_INVALID.
>
> panic_in_progress():
> Checks if a panic has been triggered.
>
> panic_on_this_cpu():
> Returns true if the current CPU is the panic originator.
>
> panic_on_other_cpu():
> Returns true if a panic is on another CPU.
>
> This change lays the groundwork for improved code readability
> and robustness in the panic handling subsystem.
>
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> ---
> include/linux/panic.h | 6 +++++
> kernel/panic.c | 53 ++++++++++++++++++++++++++++++++++++++++++
> kernel/printk/printk.c | 5 ----
> 3 files changed, 59 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/panic.h b/include/linux/panic.h
> index 7be742628c25..6f972a66c13e 100644
> --- a/include/linux/panic.h
> +++ b/include/linux/panic.h
> @@ -43,6 +43,12 @@ void abort(void);
> extern atomic_t panic_cpu;
> #define PANIC_CPU_INVALID -1
>
> +bool panic_try_start(void);
> +void panic_reset(void);
> +bool panic_in_progress(void);
> +bool panic_on_this_cpu(void);
> +bool panic_on_other_cpu(void);
> +
> /*
> * Only to be used by arch init code. If the user over-wrote the default
> * CONFIG_PANIC_TIMEOUT, honor it.
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 72fcbb5a071b..eacb0c972110 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -294,6 +294,59 @@ void __weak crash_smp_send_stop(void)
>
> atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
>
> +bool panic_try_start(void)
> +{
> + int old_cpu, this_cpu;
> +
> + /*
> + * Only one CPU is allowed to execute the crash_kexec() code as with
> + * panic(). Otherwise parallel calls of panic() and crash_kexec()
> + * may stop each other. To exclude them, we use panic_cpu here too.
> + */
> + old_cpu = PANIC_CPU_INVALID;
> + this_cpu = raw_smp_processor_id();
> +
> + return atomic_try_cmpxchg(&panic_cpu, &old_cpu, this_cpu);
> +}
> +EXPORT_SYMBOL(panic_try_start);
> +
> +void panic_reset(void)
> +{
> + atomic_set(&panic_cpu, PANIC_CPU_INVALID);
> +}
> +EXPORT_SYMBOL(panic_reset);
> +
> +bool panic_in_progress(void)
> +{
> + return unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID);
> +}
> +EXPORT_SYMBOL(panic_in_progress);
> +
> +/* Return true if a panic is in progress on the current CPU. */
> +bool panic_on_this_cpu(void)
> +{
> + /*
> + * We can use raw_smp_processor_id() here because it is impossible for
> + * the task to be migrated to the panic_cpu, or away from it. If
> + * panic_cpu has already been set, and we're not currently executing on
> + * that CPU, then we never will be.
> + */
> + return unlikely(atomic_read(&panic_cpu) == raw_smp_processor_id());
> +}
> +EXPORT_SYMBOL(panic_on_this_cpu);
> +
> +/*
> + * Return true if a panic is in progress on a remote CPU.
> + *
> + * On true, the local CPU should immediately release any printing resources
> + * that may be needed by the panic CPU.
> + */
> +bool panic_on_other_cpu(void)
> +{
> + return (panic_in_progress() && !this_cpu_in_panic());
> +}
> +EXPORT_SYMBOL(panic_on_other_cpu);
> +
> /*
> * A variant of panic() called from NMI context. We return if we've already
> * panicked on this CPU. If another CPU already panicked, loop in
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 0efbcdda9aab..5fe35f377b79 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -345,11 +345,6 @@ static void __up_console_sem(unsigned long ip)
> }
> #define up_console_sem() __up_console_sem(_RET_IP_)
>
> -static bool panic_in_progress(void)
> -{
> - return unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID);
> -}
> -
> /* Return true if a panic is in progress on the current CPU. */
> bool this_cpu_in_panic(void)
> {
All the functions are trivial. It would make sense to define
them in linux/panic.h. Then the callers would benefit
from the (unlikely) prediction macro...
It can be done in a followup path.
Otherwise, the patch looks good. I think that it is too late
but feel free to use:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: Jinchao Wang <wangjinchao600@gmail.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Baoquan He" <bhe@redhat.com>,
"Yury Norov" <yury.norov@gmail.com>,
"Qianqiang Liu" <qianqiang.liu@163.com>,
"Simona Vetter" <simona@ffwll.ch>, "Helge Deller" <deller@gmx.de>,
"Steven Rostedt" <rostedt@goodmis.org>,
"John Ogness" <john.ogness@linutronix.de>,
"Sergey Senozhatsky" <senozhatsky@chromium.org>,
"Vivek Goyal" <vgoyal@redhat.com>,
"Dave Young" <dyoung@redhat.com>, "Kees Cook" <kees@kernel.org>,
"Tony Luck" <tony.luck@intel.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Shixiong Ou" <oushixiong@kylinos.cn>,
"Zsolt Kajtar" <soci@c64.rulez.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Nam Cao" <namcao@linutronix.de>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Joel Granados" <joel.granados@kernel.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Sohil Mehta" <sohil.mehta@intel.com>,
"Feng Tang" <feng.tang@linux.alibaba.com>,
"Sravan Kumar Gundu" <sravankumarlpu@gmail.com>,
"Douglas Anderson" <dianders@chromium.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Anna Schumaker" <anna.schumaker@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
"Max Kellermann" <max.kellermann@ionos.com>,
"Yunhui Cui" <cuiyunhui@bytedance.com>,
"Tejun Heo" <tj@kernel.org>,
"Luo Gengkun" <luogengkun@huaweicloud.com>,
"Li Huafei" <lihuafei1@huawei.com>,
"Thorsten Blum" <thorsten.blum@linux.dev>,
"Yicong Yang" <yangyicong@hisilicon.com>,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
kexec@lists.infradead.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/9] panic: Introduce helper functions for panic state
Date: Tue, 16 Sep 2025 11:57:11 +0200 [thread overview]
Message-ID: <aMk0d5JO_4YECYGY@pathway.suse.cz> (raw)
In-Reply-To: <20250825022947.1596226-2-wangjinchao600@gmail.com>
On Mon 2025-08-25 10:29:29, Jinchao Wang wrote:
> This patch introduces four new helper functions to abstract the
> management of the panic_cpu variable. These functions will be used in
> subsequent patches to refactor existing code.
>
> The direct use of panic_cpu can be error-prone and ambiguous, as it
> requires manual checks to determine which CPU is handling the panic.
> The new helpers clarify intent:
>
> panic_try_start():
> Atomically sets the current CPU as the panicking CPU.
>
> panic_reset():
> Reset panic_cpu to PANIC_CPU_INVALID.
>
> panic_in_progress():
> Checks if a panic has been triggered.
>
> panic_on_this_cpu():
> Returns true if the current CPU is the panic originator.
>
> panic_on_other_cpu():
> Returns true if a panic is on another CPU.
>
> This change lays the groundwork for improved code readability
> and robustness in the panic handling subsystem.
>
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> ---
> include/linux/panic.h | 6 +++++
> kernel/panic.c | 53 ++++++++++++++++++++++++++++++++++++++++++
> kernel/printk/printk.c | 5 ----
> 3 files changed, 59 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/panic.h b/include/linux/panic.h
> index 7be742628c25..6f972a66c13e 100644
> --- a/include/linux/panic.h
> +++ b/include/linux/panic.h
> @@ -43,6 +43,12 @@ void abort(void);
> extern atomic_t panic_cpu;
> #define PANIC_CPU_INVALID -1
>
> +bool panic_try_start(void);
> +void panic_reset(void);
> +bool panic_in_progress(void);
> +bool panic_on_this_cpu(void);
> +bool panic_on_other_cpu(void);
> +
> /*
> * Only to be used by arch init code. If the user over-wrote the default
> * CONFIG_PANIC_TIMEOUT, honor it.
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 72fcbb5a071b..eacb0c972110 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -294,6 +294,59 @@ void __weak crash_smp_send_stop(void)
>
> atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
>
> +bool panic_try_start(void)
> +{
> + int old_cpu, this_cpu;
> +
> + /*
> + * Only one CPU is allowed to execute the crash_kexec() code as with
> + * panic(). Otherwise parallel calls of panic() and crash_kexec()
> + * may stop each other. To exclude them, we use panic_cpu here too.
> + */
> + old_cpu = PANIC_CPU_INVALID;
> + this_cpu = raw_smp_processor_id();
> +
> + return atomic_try_cmpxchg(&panic_cpu, &old_cpu, this_cpu);
> +}
> +EXPORT_SYMBOL(panic_try_start);
> +
> +void panic_reset(void)
> +{
> + atomic_set(&panic_cpu, PANIC_CPU_INVALID);
> +}
> +EXPORT_SYMBOL(panic_reset);
> +
> +bool panic_in_progress(void)
> +{
> + return unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID);
> +}
> +EXPORT_SYMBOL(panic_in_progress);
> +
> +/* Return true if a panic is in progress on the current CPU. */
> +bool panic_on_this_cpu(void)
> +{
> + /*
> + * We can use raw_smp_processor_id() here because it is impossible for
> + * the task to be migrated to the panic_cpu, or away from it. If
> + * panic_cpu has already been set, and we're not currently executing on
> + * that CPU, then we never will be.
> + */
> + return unlikely(atomic_read(&panic_cpu) == raw_smp_processor_id());
> +}
> +EXPORT_SYMBOL(panic_on_this_cpu);
> +
> +/*
> + * Return true if a panic is in progress on a remote CPU.
> + *
> + * On true, the local CPU should immediately release any printing resources
> + * that may be needed by the panic CPU.
> + */
> +bool panic_on_other_cpu(void)
> +{
> + return (panic_in_progress() && !this_cpu_in_panic());
> +}
> +EXPORT_SYMBOL(panic_on_other_cpu);
> +
> /*
> * A variant of panic() called from NMI context. We return if we've already
> * panicked on this CPU. If another CPU already panicked, loop in
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 0efbcdda9aab..5fe35f377b79 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -345,11 +345,6 @@ static void __up_console_sem(unsigned long ip)
> }
> #define up_console_sem() __up_console_sem(_RET_IP_)
>
> -static bool panic_in_progress(void)
> -{
> - return unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID);
> -}
> -
> /* Return true if a panic is in progress on the current CPU. */
> bool this_cpu_in_panic(void)
> {
All the functions are trivial. It would make sense to define
them in linux/panic.h. Then the callers would benefit
from the (unlikely) prediction macro...
It can be done in a followup path.
Otherwise, the patch looks good. I think that it is too late
but feel free to use:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
next prev parent reply other threads:[~2025-09-16 20:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 2:29 [PATCH v2 0/9] panic: introduce panic status function family Jinchao Wang
2025-08-25 2:29 ` [PATCH v2 1/9] panic: Introduce helper functions for panic state Jinchao Wang
2025-09-16 9:57 ` Petr Mladek [this message]
2025-09-16 9:57 ` Petr Mladek
2025-09-17 2:09 ` Jinchao Wang
2025-09-17 2:09 ` Jinchao Wang
2025-08-25 2:29 ` [PATCH v2 2/9] fbdev: Use panic_in_progress() helper Jinchao Wang
2025-08-25 2:29 ` [PATCH v2 3/9] crash_core: use panic_try_start() in crash_kexec() Jinchao Wang
2025-08-29 2:30 ` Qianqiang Liu
2025-08-29 2:30 ` Qianqiang Liu
2025-08-29 4:39 ` Jinchao Wang
2025-08-29 4:39 ` Jinchao Wang
2025-08-25 2:29 ` [PATCH v2 4/9] panic: use panic_try_start() in nmi_panic() Jinchao Wang
2025-08-25 2:29 ` [PATCH v2 5/9] panic: use panic_try_start() in vpanic() Jinchao Wang
2025-09-16 11:20 ` Petr Mladek
2025-09-16 11:20 ` Petr Mladek
2025-08-25 2:29 ` [PATCH v2 6/9] printk/nbcon: use panic_on_this_cpu() helper Jinchao Wang
2025-09-16 11:21 ` Petr Mladek
2025-09-16 11:21 ` Petr Mladek
2025-08-25 2:29 ` [PATCH v2 7/9] panic/printk: replace this_cpu_in_panic() with panic_on_this_cpu() Jinchao Wang
2025-09-16 11:22 ` Petr Mladek
2025-09-16 11:22 ` Petr Mladek
2025-08-25 2:29 ` [PATCH v2 8/9] panic/printk: replace other_cpu_in_panic() with panic_on_other_cpu() Jinchao Wang
2025-09-16 11:23 ` Petr Mladek
2025-09-16 11:23 ` Petr Mladek
2025-08-25 2:29 ` [PATCH v2 9/9] watchdog: skip checks when panic is in progress Jinchao Wang
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=aMk0d5JO_4YECYGY@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=anna.schumaker@oracle.com \
--cc=bhe@redhat.com \
--cc=cuiyunhui@bytedance.com \
--cc=deller@gmx.de \
--cc=dianders@chromium.org \
--cc=djwong@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dyoung@redhat.com \
--cc=feng.tang@linux.alibaba.com \
--cc=jgg@ziepe.ca \
--cc=joel.granados@kernel.org \
--cc=joelagnelf@nvidia.com \
--cc=john.ogness@linutronix.de \
--cc=kees@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=lihuafei1@huawei.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luogengkun@huaweicloud.com \
--cc=max.kellermann@ionos.com \
--cc=mingo@kernel.org \
--cc=namcao@linutronix.de \
--cc=oushixiong@kylinos.cn \
--cc=qianqiang.liu@163.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=simona@ffwll.ch \
--cc=soci@c64.rulez.org \
--cc=sohil.mehta@intel.com \
--cc=sravankumarlpu@gmail.com \
--cc=tglx@linutronix.de \
--cc=thorsten.blum@linux.dev \
--cc=tj@kernel.org \
--cc=tony.luck@intel.com \
--cc=tzimmermann@suse.de \
--cc=vgoyal@redhat.com \
--cc=ville.syrjala@linux.intel.com \
--cc=wangjinchao600@gmail.com \
--cc=yangyicong@hisilicon.com \
--cc=yury.norov@gmail.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 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.