All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sherry Sun <sherry.sun@nxp.com>, Jacky Bai <ping.bai@nxp.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Derek Barbosa <debarbos@redhat.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH printk v1 1/1] printk: Avoid scheduling irq_work on suspend
Date: Thu, 13 Nov 2025 12:15:47 +0100	[thread overview]
Message-ID: <aRW9439ee0NdXuyo@pathway.suse.cz> (raw)
In-Reply-To: <877bvukzs1.fsf@jogness.linutronix.de>

On Thu 2025-11-13 11:17:42, John Ogness wrote:
> On 2025-11-13, Petr Mladek <pmladek@suse.com> wrote:
> >> I would prefer to keep all the printk_get_console_flush_type() changes
> >> since it returns proper available flush type information. If you would
> >> like to _additionally_ short-circuit __wake_up_klogd() and
> >> nbcon_kthreads_wake() in order to avoid all possible irq_work queueing,
> >> I would be OK with that.
> >
> > Combining both approaches might be a bit messy. Some code paths might
> > work correctly because of the explicit check and some just by chance.
> >
> > But I got an idea. We could add a warning into __wake_up_klogd()
> > and nbcon_kthreads_wake() to report when they are called unexpectedly.
> >
> > And we should also prevent calling it from lib/nmi_backtrace.c.
> >
> > I played with it and came up with the following changes on
> > top of this patch:
> >
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 334b4edff08c..e9290c418d12 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -4637,6 +4644,21 @@ void defer_console_output(void)
> >  	__wake_up_klogd(PRINTK_PENDING_WAKEUP | PRINTK_PENDING_OUTPUT);
> >  }
> >  
> > +void printk_try_flush(void)
> > +{
> > +	struct console_flush_type ft;
> > +
> > +	printk_get_console_flush_type(&ft);
> > +	if (ft.nbcon_atomic)
> > +		nbcon_atomic_flush_pending();
> 
> For completeness, we should probably also have here:
> 
> 	if (ft.nbcon_offload)
> 		nbcon_kthreads_wake();

Makes sense. I think that did not add it because I got scared by
the _wake suffix. I forgot that it just queued the irq_work.


> > +	if (ft.legacy_direct) {
> > +		if (console_trylock())
> > +			console_unlock();
> > +	}
> > +	if (ft.legacy_offload)
> > +		defer_console_output();
> > +}
> > +
> >  void printk_trigger_flush(void)
> >  {
> >  	defer_console_output();
> > diff --git a/lib/nmi_backtrace.c b/lib/nmi_backtrace.c
> > index 33c154264bfe..632bbc28cb79 100644
> > --- a/lib/nmi_backtrace.c
> > +++ b/lib/nmi_backtrace.c
> > @@ -78,10 +78,10 @@ void nmi_trigger_cpumask_backtrace(const cpumask_t *mask,
> >  	nmi_backtrace_stall_check(to_cpumask(backtrace_mask));
> >  
> >  	/*
> > -	 * Force flush any remote buffers that might be stuck in IRQ context
> > +	 * Try flushing messages added CPUs which might be stuck in IRQ context
> >  	 * and therefore could not run their irq_work.
> >  	 */
> > -	printk_trigger_flush();
> > +	printk_try_flush();
> >  
> >  	clear_bit_unlock(0, &backtrace_flag);
> >  	put_cpu();
> >
> > How does it look, please?
> 
> I like this. But I think the printk_try_flush() implementation should
> simply replace the implementation of printk_trigger_flush().

Make sense.

> For the arch/powerpc/kernel/watchdog.c:watchdog_timer_interrupt() and
> lib/nmi_backtrace.c:nmi_trigger_cpumask_backtrace() sites I think it is
> appropriate.

Yup.

> For the kernel/printk/nbcon.c:nbcon_device_release() site I think the
> call should be changed to defer_console_output():
> 
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index 558ef31779760..73f315fd97a3e 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1849,7 +1849,7 @@ void nbcon_device_release(struct console *con)
>  			if (console_trylock())
>  				console_unlock();
>  		} else if (ft.legacy_offload) {
> -			printk_trigger_flush();
> +			defer_console_output();
>  		}
>  	}
>  	console_srcu_read_unlock(cookie);

Looks good.

> Can I fold all that into a new patch?

Go ahead.

Best Regards,
Petr

  reply	other threads:[~2025-11-13 11:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 14:43 [PATCH printk v1 0/1] Fix reported suspend failures John Ogness
2025-11-11 14:43 ` [PATCH printk v1 1/1] printk: Avoid scheduling irq_work on suspend John Ogness
2025-11-11 16:31   ` Petr Mladek
2025-11-12 15:50     ` John Ogness
2025-11-13  9:52       ` Petr Mladek
2025-11-13 10:11         ` John Ogness
2025-11-13 11:15           ` Petr Mladek [this message]
2025-11-12  5:00   ` Sherry Sun

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=aRW9439ee0NdXuyo@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=debarbos@redhat.com \
    --cc=john.ogness@linutronix.de \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ping.bai@nxp.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=sherry.sun@nxp.com \
    --cc=stable@vger.kernel.org \
    --cc=thierry.reding@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.