All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jinchao Wang <wangjinchao600@gmail.com>
To: Petr Mladek <pmladek@suse.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: Wed, 17 Sep 2025 10:09:12 +0800	[thread overview]
Message-ID: <aMoYSElAEBiBvVET@mdev> (raw)
In-Reply-To: <aMk0d5JO_4YECYGY@pathway.suse.cz>

On Tue, Sep 16, 2025 at 11:57:11AM +0200, Petr Mladek wrote:
> 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.
Thanks for feedback, I will do it later.

BTW, this series was merged to -mm branch already.

> 
> 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

-- 
Jinchao


WARNING: multiple messages have this Message-ID (diff)
From: Jinchao Wang <wangjinchao600@gmail.com>
To: Petr Mladek <pmladek@suse.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: Wed, 17 Sep 2025 10:09:12 +0800	[thread overview]
Message-ID: <aMoYSElAEBiBvVET@mdev> (raw)
In-Reply-To: <aMk0d5JO_4YECYGY@pathway.suse.cz>

On Tue, Sep 16, 2025 at 11:57:11AM +0200, Petr Mladek wrote:
> 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.
Thanks for feedback, I will do it later.

BTW, this series was merged to -mm branch already.

> 
> 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

-- 
Jinchao

  reply	other threads:[~2025-09-17 12:18 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
2025-09-16  9:57     ` Petr Mladek
2025-09-17  2:09     ` Jinchao Wang [this message]
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=aMoYSElAEBiBvVET@mdev \
    --to=wangjinchao600@gmail.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=pmladek@suse.com \
    --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=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.