[PATCH printk v6 00/17] add threaded printing + the rest

John Ogness posted 17 patches 1 year, 3 months ago
drivers/tty/tty_io.c              |   2 +-
fs/proc/consoles.c                |   7 +-
include/linux/console.h           |  48 +++
kernel/printk/internal.h          |  82 ++++-
kernel/printk/nbcon.c             | 507 +++++++++++++++++++++++++-----
kernel/printk/printk.c            | 467 ++++++++++++++++++++++++---
kernel/printk/printk_ringbuffer.h |   2 +
kernel/printk/printk_safe.c       |   4 +-
8 files changed, 986 insertions(+), 133 deletions(-)
[PATCH printk v6 00/17] add threaded printing + the rest
Posted by John Ogness 1 year, 3 months ago
Hi,

This is v6 of a series to implement threaded console printing
as well as some other minor pieces (such as proc and sysfs
recognition of nbcon consoles). v5 is here [0].

For information about the motivation of the nbcon consoles,
please read the cover letter of the original v1 [1].

This series provides the remaining pieces of the printk
rework. All other components are either already mainline or are
currently in linux-next. In particular this series does:

- Implement dedicated printing threads per nbcon console.

- Implement forced threading of legacy consoles for PREEMPT_RT.

- Implement nbcon support for proc and sysfs console-related
  files.

- Provide a new helper function nbcon_reacquire_nobuf() to
  allow nbcon console drivers to reacquire ownership.

Note that this series does *not* provide an nbcon console
driver. That will come in a follow-up series.

Here are the changes since v5:

- In nbcon_kthreads_wake(), skip !CON_NBCON consoles.

- In console_flush_all(), also skip nbcon consoles if
  ft.nbcon_atomic == true and improve comments explaining
  why.

- In legacy_kthread_should_wakeup(), also skip nbcon consoles
  if ft.nbcon_atomic == true and improve comments explaining
  why.

John Ogness

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

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

John Ogness (16):
  printk: nbcon: Add function for printers to reacquire ownership
  printk: Fail pr_flush() if before SYSTEM_SCHEDULING
  printk: Flush console on unregister_console()
  printk: nbcon: Add context to usable() and emit()
  printk: nbcon: Init @nbcon_seq to highest possible
  printk: nbcon: Relocate nbcon_atomic_emit_one()
  printk: nbcon: Use thread callback if in task context for legacy
  printk: nbcon: Rely on kthreads for normal operation
  printk: Provide helper for message prepending
  printk: nbcon: Show replay message on takeover
  proc: consoles: Add notation to c_start/c_stop
  proc: Add nbcon support for /proc/consoles
  tty: sysfs: Add nbcon support for 'active'
  printk: Implement legacy printer kthread for PREEMPT_RT
  printk: nbcon: Assign nice -20 for printing threads
  printk: Avoid false positive lockdep report for legacy printing

Thomas Gleixner (1):
  printk: nbcon: Introduce printer kthreads

 drivers/tty/tty_io.c              |   2 +-
 fs/proc/consoles.c                |   7 +-
 include/linux/console.h           |  48 +++
 kernel/printk/internal.h          |  82 ++++-
 kernel/printk/nbcon.c             | 507 +++++++++++++++++++++++++-----
 kernel/printk/printk.c            | 467 ++++++++++++++++++++++++---
 kernel/printk/printk_ringbuffer.h |   2 +
 kernel/printk/printk_safe.c       |   4 +-
 8 files changed, 986 insertions(+), 133 deletions(-)


base-commit: d33d5e683b0d3b4f5fc6a49ce17583f8ca663944
-- 
2.39.2
Re: [PATCH printk v6 00/17] add threaded printing + the rest
Posted by Petr Mladek 1 year, 3 months ago
On Wed 2024-09-04 14:11:19, John Ogness wrote:
> Hi,
> 
> This is v6 of a series to implement threaded console printing
> as well as some other minor pieces (such as proc and sysfs
> recognition of nbcon consoles). v5 is here [0].
> 
> For information about the motivation of the nbcon consoles,
> please read the cover letter of the original v1 [1].
> 
> This series provides the remaining pieces of the printk
> rework. All other components are either already mainline or are
> currently in linux-next. In particular this series does:
> 
> - Implement dedicated printing threads per nbcon console.
> 
> - Implement forced threading of legacy consoles for PREEMPT_RT.
> 
> - Implement nbcon support for proc and sysfs console-related
>   files.
> 
> - Provide a new helper function nbcon_reacquire_nobuf() to
>   allow nbcon console drivers to reacquire ownership.
> 
> Note that this series does *not* provide an nbcon console
> driver. That will come in a follow-up series.

JFYI, the patchset has been committed into printk/linux.git,
branch rework/threaded-printk.

I am not completely sure if we add this early enough for 6.12.
On one hand, the patchset should not change the handling of legacy
consoles and it does not add any nbcon console. But it touches
many code paths where we decide how to flush the consoles
and could imagine doing "ugly" mistakes there.

OK, let's see how it works in linux-next in the following days.
There is still time to catch problems and make the decision.

Best Regards,
Petr
Re: [PATCH printk v6 00/17] add threaded printing + the rest
Posted by John Ogness 1 year, 3 months ago
On 2024-09-04, Petr Mladek <pmladek@suse.com> wrote:
> JFYI, the patchset has been committed into printk/linux.git,
> branch rework/threaded-printk.

Thanks!

> I am not completely sure if we add this early enough for 6.12.
> On one hand, the patchset should not change the handling of legacy
> consoles and it does not add any nbcon console. But it touches
> many code paths where we decide how to flush the consoles
> and could imagine doing "ugly" mistakes there.
>
> OK, let's see how it works in linux-next in the following days.
> There is still time to catch problems and make the decision.

I just don't think there are many real users of linux-next. The code
leading to the 5.19 revert sat in linux-next for a long time and no one
noticed anything. It wasn't until the 5.19-rc's started coming out that
real testing (and bug reporting) occurred.

I think linux-next is great for the kernel robots to work their magic,
but I don't know if having something in linux-next for 6 weeks is any
better than only 2 weeks.

John