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>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: wake_up_klogd(): was: Re: [PATCH printk v2 10/12] printk: add kthread console printers
Date: Thu, 7 Apr 2022 18:53:59 +0200	[thread overview]
Message-ID: <Yk8XJ7NX2JGOQLna@alley> (raw)
In-Reply-To: <20220405132535.649171-11-john.ogness@linutronix.de>

On Tue 2022-04-05 15:31:33, John Ogness wrote:
> Create a kthread for each console to perform console printing. During
> normal operation (@system_state == SYSTEM_RUNNING), the kthread
> printers are responsible for all printing on their respective
> consoles.
> 
> During non-normal operation, console printing is done as it has been:
> within the context of the printk caller or within irq work triggered
> by the printk caller.
> 
> Console printers synchronize against each other and against console
> lockers by taking the console lock for each message that is printed.
> 
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3445,40 +3659,64 @@ static void wake_up_klogd_work_func(struct irq_work *irq_work)
>  	int pending = this_cpu_xchg(printk_pending, 0);
>  
>  	if (pending & PRINTK_PENDING_OUTPUT) {
> +		printk_prefer_direct_enter();

Please, rename PRINTK_PENDING_OUTPUT to PRINTK_PENDING_DIRECT_OUTPUT.

The change confused me a lot. I wrote many lines about why it is
(not) needed. Then I continued the review and found that it started making
sense after the change in defer_console_output(). ;-)

This patch changes the meaning of the flag. It would deserve renaming.

> +
>  		/* If trylock fails, someone else is doing the printing */
>  		if (console_trylock())
>  			console_unlock();
> +
> +		printk_prefer_direct_exit();
>  	}
>  
>  	if (pending & PRINTK_PENDING_WAKEUP)
> -		wake_up_interruptible(&log_wait);
> +		wake_up_interruptible_all(&log_wait);

This would deserve some explanation in the commit message.
I think that this actually was needed even before. IMHO, more
pending waiters had to wait for more new messages. It was
not guaranteed the the woken waiter woke another one.

It would be nice to put it into separate patch and do it first.

>  }
>  
>  static DEFINE_PER_CPU(struct irq_work, wake_up_klogd_work) =
>  	IRQ_WORK_INIT_LAZY(wake_up_klogd_work_func);
>  
> -void wake_up_klogd(void)
> +static void __wake_up_klogd(int val)
>  {
>  	if (!printk_percpu_data_ready())
>  		return;
>  
>  	preempt_disable();
> -	if (waitqueue_active(&log_wait)) {
> -		this_cpu_or(printk_pending, PRINTK_PENDING_WAKEUP);
> +	/*
> +	 * Guarantee any new records can be seen by printing threads before
> +	 * checking if the wait queue is empty.
> +	 *
> +	 * The full memory barrier within wq_has_sleeper() pairs with the full
> +	 * memory barrier within set_current_state() of
> +	 * prepare_to_wait_event(), which is called after ___wait_event() adds
> +	 * the waiter but before it has checked the wait condition.
> +	 *
> +	 * See printk_kthread_func:A for the pairing memory barrier.
> +	 */

I guess that this problem was there even before but it was less
visible. Do I get it correctly, please?


> +	if (wq_has_sleeper(&log_wait) || /* LMM(__wake_up_klogd:A) */
> +	    (val & PRINTK_PENDING_OUTPUT)) {
> +		this_cpu_or(printk_pending, val);
>  		irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
>  	}
>  	preempt_enable();
>  }
>  
> +void wake_up_klogd(void)
> +{
> +	__wake_up_klogd(PRINTK_PENDING_WAKEUP);
> +}
> +
>  void defer_console_output(void)
>  {
> -	if (!printk_percpu_data_ready())
> -		return;

	/* Always wakeup waiters because there are not only printk kthreads. */
> +	int val = PRINTK_PENDING_WAKEUP;

IMHO, this was actually needed even before. Otherwise, nobody woken
log waiters for deferred messages.

IMHO, it is a regression caused by moving wake_up_klogd() from
console_unlock() to vprintk_emit(). It was the commit
43a17111c2553925f6 ("printk: wake up klogd in vprintk_emit").

If I am right then we should fix it separately.


> -	preempt_disable();
> -	this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> -	irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
> -	preempt_enable();
> +	/*
> +	 * If console deferring was called with preferred direct printing,
> +	 * make the irqwork perform the direct printing.
> +	 */
> +	if (atomic_read(&printk_prefer_direct))
> +		val |= PRINTK_PENDING_OUTPUT;
> +
> +	__wake_up_klogd(val);
>  }

And we should call defer_console_output() also in
printk_prefer_direct_enter() to make sure that a potential
pending messages are printed.

My understanding is that the kthreads stop processing the messages
when the direct output is preferred. I think that this was not
the case in v1 and I asked you do it this way so that kthreads
do not block entering the direct mode.

Best Regards,
Petr

  parent reply	other threads:[~2022-04-07 16:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 13:25 [PATCH printk v2 00/12] implement threaded console printing John Ogness
2022-04-05 13:25 ` [PATCH printk v2 01/12] printk: rename cpulock functions John Ogness
2022-04-06  9:07   ` Petr Mladek
2022-04-05 13:25 ` [PATCH printk v2 02/12] printk: cpu sync always disable interrupts John Ogness
2022-04-05 13:25 ` [PATCH printk v2 03/12] printk: get caller_id/timestamp after migration disable John Ogness
2022-04-05 13:25 ` [PATCH printk v2 04/12] printk: call boot_delay_msec() in printk_delay() John Ogness
2022-04-05 13:25 ` [PATCH printk v2 05/12] printk: add macro for console detail messages John Ogness
2022-04-06 10:31   ` Petr Mladek
2022-04-05 13:25 ` [PATCH printk v2 06/12] printk: refactor and rework printing logic John Ogness
2022-04-06 14:02   ` Petr Mladek
2022-04-05 13:25 ` [PATCH printk v2 07/12] printk: move buffer definitions into console_emit_next_record() caller John Ogness
2022-04-06 14:40   ` Petr Mladek
2022-04-05 13:25 ` [PATCH printk v2 08/12] printk: add pr_flush() John Ogness
2022-04-06 15:17   ` Petr Mladek
2022-04-08 18:57     ` John Ogness
2022-04-05 13:25 ` [PATCH printk v2 09/12] printk: add functions to prefer direct printing John Ogness
2022-04-07  9:56   ` Petr Mladek
2022-04-07 13:35     ` Helge Deller
2022-04-07 14:35       ` John Ogness
2022-04-07 19:36         ` Helge Deller
2022-04-07 20:04           ` John Ogness
2022-04-07 20:20             ` Helge Deller
2022-04-11 12:50               ` Petr Mladek
2022-04-09 15:57   ` Paul E. McKenney
2022-04-05 13:25 ` [PATCH printk v2 10/12] printk: add kthread console printers John Ogness
2022-04-07 16:43   ` start/stop: was: " Petr Mladek
2022-04-07 16:49   ` console_is_usable() check: " Petr Mladek
2022-04-07 16:53   ` Petr Mladek [this message]
2022-04-07 16:56   ` console_flush_all(): was: : was " Petr Mladek
2022-04-05 13:25 ` [PATCH printk v2 11/12] printk: extend console_lock for proper kthread support John Ogness
2022-04-08 13:45   ` guarantee forward progress: was: " Petr Mladek
2022-04-08 20:17     ` John Ogness
2022-04-11 10:45       ` Petr Mladek
2022-04-08 13:52   ` register_console: " Petr Mladek
2022-04-05 13:25 ` [PATCH printk v2 12/12] printk: remove @console_locked John Ogness
2022-04-05 15:03 ` [PATCH printk v2 00/12] implement threaded console printing Andy Shevchenko
2022-04-05 21:24   ` 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=Yk8XJ7NX2JGOQLna@alley \
    --to=pmladek@suse.com \
    --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 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.