linux-kernel.vger.kernel.org archive mirror
 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>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Helge Deller <deller@gmx.de>
Subject: Re: [PATCH printk v3 13/15] printk: add kthread console printers
Date: Thu, 21 Apr 2022 16:25:03 +0200	[thread overview]
Message-ID: <20220421141921.GD11747@pathway.suse.cz> (raw)
In-Reply-To: <87h76nwmjk.fsf@jogness.linutronix.de>

On Wed 2022-04-20 22:08:39, John Ogness wrote:
> On 2022-04-20, Petr Mladek <pmladek@suse.com> wrote:
> > On Wed 2022-04-20 01:52:35, John Ogness wrote:
> >> @@ -2280,10 +2295,10 @@ asmlinkage int vprintk_emit(int facility, int level,
> >>  	printed_len = vprintk_store(facility, level, dev_info, fmt, args);
> >>  
> >>  	/* If called from the scheduler, we can not call up(). */
> >> -	if (!in_sched) {
> >> +	if (!in_sched && allow_direct_printing()) {
> >
> > allow_direct_printing() is racy here. But I think that we could live
> > with it, see below.
> 
> Well, it is not racy for its intended purpose, which is a context that
> does:
> 
> printk_prefer_direct_enter();
> printk();
> printk_prefer_direct_exit();
> 
> It is only racy for _other_ contexts that might end up direct
> printing. But since those other contexts don't have a preference, I see
> no problem with it.

Make sense.

Let me think more about it. To be sure that we see all aspects:

There are also other system wide variables checked by
allow_direct_printing() and can be modified asynchronously:

	+ printk_kthreads_available
	+ system_state
	+ oops_in_progress

"oops_in_progress" and "system_state" are similar to
"printk_prefer_direct". The context that modifies this
variable will see the right value. The other contexts
do not care that much and do not need to be strictly
synchronized. Also the value means that the direct
mode is preferred but it is never guaranteed and
never was.

"printk_kthreads_available" is more tricky.
__printk_fallback_preferred_direct() causes that printk kthreads
will not be used any longer. It should make sure that the pending
messages will be printed directly. And it works because
it is called under console_lock and the pending messages
will be printed by the console_unlock().

Everything looks fine after all. I wonder if we could somehow
document it somewhere. I think about adding a comment
above allow_direct_printing() definition:

/*
 * printk() always wakes printk kthreads so that they could
 * flush the new message to the consoles. Also it tries
 * the flush the messages directly when it is allowed.
 *
 * The direct priting is allowed in situations when the kthreads
 * are not available or the system is in a problematic state.
 *
 * See the implementation about possible races.
 */
static inline bool allow_direct_printing(void)
{
	/*
	 * The kthreads are disabled under console_lock.
	 * Any pending messages will be handled by
	 * console_unlock().
	 */
	if (!printk_kthreads_available)
		return false;

	/*
	 * Prefer direct printing when the system is in a problematic
	 * state. The context that sets this state will always see
	 * the updated value. The other contexts do not care that
	 * much. Anyway, it is just a best effort. The direct output
	 * is possible only when console_lock is not already taken.
	 */
	return (system_state > SYSTEM_RUNNING ||
		oops_in_progress ||
		atomic_read(&printk_prefer_direct));
}

Best Regards,
Petr

  reply	other threads:[~2022-04-21 14:25 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 23:46 [PATCH printk v3 00/15] printk/for-next John Ogness
2022-04-19 23:46 ` [PATCH printk v3 01/15] printk: rename cpulock functions John Ogness
2022-04-19 23:46 ` [PATCH printk v3 02/15] printk: cpu sync always disable interrupts John Ogness
2022-04-19 23:46 ` [PATCH printk v3 03/15] printk: add missing memory barrier to wake_up_klogd() John Ogness
2022-04-20 12:34   ` Petr Mladek
2022-04-19 23:46 ` [PATCH printk v3 04/15] printk: wake up all waiters John Ogness
2022-04-20 12:36   ` Petr Mladek
2022-04-19 23:46 ` [PATCH printk v3 05/15] printk: wake waiters for safe and NMI contexts John Ogness
2022-04-20 13:55   ` Petr Mladek
2022-04-19 23:46 ` [PATCH printk v3 06/15] printk: get caller_id/timestamp after migration disable John Ogness
2022-04-19 23:46 ` [PATCH printk v3 07/15] printk: call boot_delay_msec() in printk_delay() John Ogness
2022-04-19 23:46 ` [PATCH printk v3 08/15] printk: add con_printk() macro for console details John Ogness
2022-04-20 14:01   ` Petr Mladek
2022-04-19 23:46 ` [PATCH printk v3 09/15] printk: refactor and rework printing logic John Ogness
2022-04-20 14:55   ` Petr Mladek
2022-04-19 23:46 ` [PATCH printk v3 10/15] printk: move buffer definitions into console_emit_next_record() caller John Ogness
2022-04-19 23:46 ` [PATCH printk v3 11/15] printk: add pr_flush() John Ogness
2022-04-20 15:10   ` Petr Mladek
2022-04-19 23:46 ` [PATCH printk v3 12/15] printk: add functions to prefer direct printing John Ogness
2022-04-19 23:46 ` [PATCH printk v3 13/15] printk: add kthread console printers John Ogness
2022-04-20 17:53   ` Petr Mladek
2022-04-20 20:02     ` John Ogness
2022-04-21 14:25       ` Petr Mladek [this message]
2022-04-19 23:46 ` [PATCH printk v3 14/15] printk: extend console_lock for proper kthread support John Ogness
2022-04-20  2:13   ` kernel test robot
2022-04-20 13:32     ` John Ogness
2022-04-20  4:04   ` kernel test robot
2022-04-21 12:41   ` Petr Mladek
2022-04-21 14:30     ` John Ogness
2022-04-22 13:03       ` Petr Mladek
2022-04-22 14:14         ` John Ogness
2022-04-22 15:15           ` Petr Mladek
2022-04-22 21:25             ` John Ogness
2022-04-25 15:18               ` Petr Mladek
2022-04-25 19:10                 ` John Ogness
2022-04-19 23:46 ` [PATCH printk v3 15/15] printk: remove @console_locked John Ogness
2022-04-21 12:46   ` Petr Mladek
2022-04-21 14:40 ` [PATCH printk v3 00/15] printk/for-next Petr Mladek
2022-04-21 15:02   ` John Ogness

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=20220421141921.GD11747@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=deller@gmx.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    /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).