Re: [PATCH] mm: Fix possible deadlock in console_trylock_spinning

[John Ogness <john.ogness@linutronix.de>]

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