This is v3 of a series to implement a kthread for each registered
console. v2 is here [0]. The kthreads locklessly retrieve the
records from the printk ringbuffer and also do not cause any lock
contention between each other. This allows consoles to run at full
speed. For example, a netconsole is able to dump records much
faster than a serial or vt console. Also, during normal operation,
printk() callers are completely decoupled from console printing.

There are situations where kthread printing is not sufficient. For
example, during panic situations, where the kthreads may not get a
chance to schedule. In such cases, the current method of attempting
to print directly within the printk() caller context is used. New
functions printk_prefer_direct_enter() and
printk_prefer_direct_exit() are made available to mark areas of the
kernel where direct printing is preferred. (These should only be
areas that do not occur during normal operation.)

This series also introduces pr_flush(): a might_sleep() function
that will block until all active printing threads have caught up
to the latest record at the time of the pr_flush() call. This
function is useful, for example, to wait until pending records
are flushed to consoles before suspending.

Note that this series does *not* increase the reliability of console
printing. Rather it focuses on the non-interference aspect of
printk() by decoupling printk() callers from printing (during normal
operation). Nonetheless, the reliability aspect should not worsen
due to this series.

John Ogness

[0] https://lore.kernel.org/lkml/20220405132535.649171-1-john.ogness@linutronix.de

Changes since v2:

- Threaded printers no longer care about preferred direct printing.
  As with v1, they will print whenever they are not blocked.

- Provide a separate patch to fix a missing memory barrier in
  wake_up_klogd() and add memory barrier comments to all
  appropriate @log_wait usage sites.

- Provide a separate patch to wake all waiters.

- Provide a separate patch to wake waiters for deferred console
  output and add comments explaining why.

- Introduce console_lock_single_hold() and
  console_unlock_single_release() to acquire @console_sem and lock a
  single threaded printer. This allows console start/stop and
  console unregistration with synchronized con->flags and without
  disturbing other threaded printers.

- Introduce __console_is_usable() to avoid some redundance between
  threaded and direct printing code.

- Do not create a printer thread if con->write() is not set. (I do
  not understand why we even allow registration if con->write() is
  not set. The checks were added in 2.1.31 for no obvious reason.)

- Only allow handovers between console_trylock() contexts. A
  console_lock() context cannot handover the console_lock to a
  console_trylock() context because the blocked kthreads would need
  to be unblocked via mutex.

- console_flush_all() returns true only if at least one console is
  usable and all messages to all usable consoles were printed.
  Otherwise it returns false.

- Remove redundant panic check in console_unlock().

- Rename printk_console_msg() to con_printk() and use syntax similar
  to dev_printk(). (I did not name it console_printk() because there
  already exists a symbol with that name.)

- Remove blocked check in register_console() since it is always
  true.

- In unregister_console(), stop the kthread after the console has
  been removed from the list. Use the per-console mutex for
  synchronized kthread stopping.

- Use the console_lock for synchronized activation of the fallback
  permanent direct printing mode.

- Use the same checks in printer_should_wake() as in
  printk_kthread_func() to avoid infinite loop danger.

- Rename PRINTK_PENDING_OUTPUT flag to PRINTK_PENDING_DIRECT_OUTPUT.

- Expand commit messages relating to memory barriers, kthreads, and
  the usage of the per-console mutex.

John Ogness (15):
  printk: rename cpulock functions
  printk: cpu sync always disable interrupts
  printk: add missing memory barrier to wake_up_klogd()
  printk: wake up all waiters
  printk: wake waiters for safe and NMI contexts
  printk: get caller_id/timestamp after migration disable
  printk: call boot_delay_msec() in printk_delay()
  printk: add con_printk() macro for console details
  printk: refactor and rework printing logic
  printk: move buffer definitions into console_emit_next_record() caller
  printk: add pr_flush()
  printk: add functions to prefer direct printing
  printk: add kthread console printers
  printk: extend console_lock for proper kthread support
  printk: remove @console_locked

 drivers/tty/sysrq.c     |    2 +
 include/linux/console.h |   19 +
 include/linux/printk.h  |   82 ++-
 kernel/hung_task.c      |   11 +-
 kernel/panic.c          |    4 +
 kernel/printk/printk.c  | 1197 +++++++++++++++++++++++++++++----------
 kernel/rcu/tree_stall.h |    2 +
 kernel/reboot.c         |   14 +-
 kernel/watchdog.c       |    4 +
 kernel/watchdog_hld.c   |    4 +
 lib/dump_stack.c        |    4 +-
 lib/nmi_backtrace.c     |    4 +-
 12 files changed, 1021 insertions(+), 326 deletions(-)


base-commit: 84d7df104dbab9c3dda8f2c5b46f9a6fc256fe02
-- 
2.30.2

On Wed 2022-04-20 01:52:22, John Ogness wrote:
> This is v3 of a series to implement a kthread for each registered
> console. v2 is here [0]. The kthreads locklessly retrieve the
> records from the printk ringbuffer and also do not cause any lock
> contention between each other. This allows consoles to run at full
> speed. For example, a netconsole is able to dump records much
> faster than a serial or vt console. Also, during normal operation,
> printk() callers are completely decoupled from console printing.
> 
> There are situations where kthread printing is not sufficient. For
> example, during panic situations, where the kthreads may not get a
> chance to schedule. In such cases, the current method of attempting
> to print directly within the printk() caller context is used. New
> functions printk_prefer_direct_enter() and
> printk_prefer_direct_exit() are made available to mark areas of the
> kernel where direct printing is preferred. (These should only be
> areas that do not occur during normal operation.)
> 
> This series also introduces pr_flush(): a might_sleep() function
> that will block until all active printing threads have caught up
> to the latest record at the time of the pr_flush() call. This
> function is useful, for example, to wait until pending records
> are flushed to consoles before suspending.
> 
> Note that this series does *not* increase the reliability of console
> printing. Rather it focuses on the non-interference aspect of
> printk() by decoupling printk() callers from printing (during normal
> operation). Nonetheless, the reliability aspect should not worsen
> due to this series.

This series looks almost ready for linux-next. The only real
problems are:

   + Use allow_direct_printing() instead of
     atomic_read(&printk_prefer_direct) in defer_console_output()

   + "temporary" remove
     console_lock_single_hold()/console_lock_single_release() and
     use the full console_lock()/console_unlock() instead.

The rest are few cosmetic issues.

I would like to push this into linux-next ASAP so that we get some
wider testing of this approach. I do not expect that we could find
much more issues just by staring into the code ;-)

Now, the question is whether I should wait for v4. Or whether
I should put v3 into linux-next with a follow up patch doing
the two above suggested changes. They are quite trivial.

Anyway, if I pushed v3+fixup then I would replace it with v4, v5, ...
once they are available. I just do not want to block testing because
of cosmetic problems.

John, what is your preference, please?
Anybody has another opinion, please?

Best Regards,
Petr

On 2022-04-21, Petr Mladek <pmladek@suse.com> wrote:
> This series looks almost ready for linux-next. The only real
> problems are:
>
>    + Use allow_direct_printing() instead of
>      atomic_read(&printk_prefer_direct) in defer_console_output()
>
>    + "temporary" remove
>      console_lock_single_hold()/console_lock_single_release() and
>      use the full console_lock()/console_unlock() instead.
>
> The rest are few cosmetic issues.
>
> I would like to push this into linux-next ASAP so that we get some
> wider testing of this approach. I do not expect that we could find
> much more issues just by staring into the code ;-)
>
> Now, the question is whether I should wait for v4. Or whether
> I should put v3 into linux-next with a follow up patch doing
> the two above suggested changes. They are quite trivial.
>
> Anyway, if I pushed v3+fixup then I would replace it with v4, v5, ...
> once they are available. I just do not want to block testing because
> of cosmetic problems.

Even though the fixup may be straight-forward, it would be touching a
lot of lines and could potentially introduce new problems. I prefer you
wait for a v4 so that there is no mess to clean up.

I can post a v4 tomorrow (using option #1 from [0] as the
synchronization alternative).

John

[0] https://lore.kernel.org/r/875yn2h5ku.fsf@jogness.linutronix.de