On 2025-08-01, Waiman Long llong@redhat.com wrote:
kmemleak_scan_thread() invokes scan_block() which may invoke a nomal printk() to print warning message. This can cause a deadlock in the scenario reported below:
CPU0 CPU1 ---- ----
lock(kmemleak_lock); lock(&port->lock); lock(kmemleak_lock); lock(console_owner);
To solve this problem, switch to printk_safe mode before printing warning message, this will redirect all printk()-s to a special per-CPU buffer, which will be flushed later from a safe context (irq work), and this deadlock problem can be avoided.
printk no longer works like this. There are no special per-CPU buffers. As correctly pointed out by Longman, the proper interface is printk_deferred_enter()/printk_deferred_exit().
With the deferred interface, the printk message is still immediately stored in the printk ringbuffer (which is lockless) and only the console printing itself is deferred.
John Ogness