Re: [Question] printk-basics.rst: propose adding warning about high-frequency printk causing lockup on serial console

On Tue 2026-03-03 15:34:18, BACKPACK wrote:

Hi linux-doc maintainers, 


I'm working on an embedded/arm64 system where high-frequency printk() calls (e.g., in network RX interrupt or timer handler) occasionally trigger "hard lockup" or "soft lockup" detector, especially when console=ttyS0 is used. The root cause is that printk() may acquire console_sem and flush logs to a slow serial device, blocking interrupts for too long. 
 
I'd like to propose adding a short note in Documentation/core-api/printk-basics.rst to warn developers about this pitfall and suggest alternatives like:
 - Using tracepoints (ftrace) 

There is also trace_printk() which can be added in temporary
debugging patches. Note that trace_printk() should not be
added into the mainline code, see the section about trace_printk()
in Documentation/trace/debugging.rst.

 - Rate-limiting with pr_xxx_ratelimited() 
 - Avoiding printk in hot paths 

There is also pr_*_once(). It is a good alternative for hot paths
especially when the reported event should never happen.

Another trick is using less important loglevel for less important
messages and use console_loglevel to filter them on consoles.
There is a patchset which would allow to define per-console loglevels,
see the last version at
https://lore.kernel.org/r/cover.1764272407.git.chris@chrisdown.name (local)

Finally, the risk of printk-related lockups is lower when using a console
driver converted to nbcon API, see CON_NBCON flag. They flush printk()
messages flushed in a dedicated printk thread except for emergency
and panic contexts. Unfortunately, most console drivers have not
been converted yet.

Note that the nbcon console drivers might have another problem.
The asynchronous printing increases the risk that the messages
might be lost before they are flushed. A bigger log buffer might
help in this case.

Before preparing a formal patch, I'd like to ask: 
1. Is this the right place to document this? 

printk-basics.rst looks like a good place to me.

2. Would the community find this guidance useful?

Yes.

3. Any suggestions on wording or examples? 

Please, write the documenation using an imperative mood. Especially
avoid "you/we" ...

Also note that the documentation is written in reStructuredText (.rst)
format, see https://docutils.sourceforge.io/rst.html
and https://docs.kernel.org/doc-guide/sphinx.html

 This would be my first contribution to kernel documentation, so I appreciate your patience and guidance. Thanks, 
hujinfei <3288824963@qq.com&gt;

I am looking forward to see a patch.

Best Regards,
Petr