On Wed, Nov 10, 2021 at 11:50:38AM +0100, Petr Mladek wrote:
On Tue 2021-11-09 12:06:48, Sultan Alsawaf wrote:
Hi,
I encountered a printk deadlock on 5.13 which appears to still affect the latest kernel. The deadlock occurs due to printk being used while having the current CPU's runqueue locked, and the underlying framebuffer console attempting to lock the same runqueue when printk tries to flush the log buffer.
I'm not sure what the *correct* solution is here (don't use printk while having a runqueue locked? don't use schedule_work() from the fbcon path? tell printk to use one of its lock-less backends?), so I've cc'd all the relevant folks.
At the moment, printk_deferred() could be used here. It defers the console handling via irq_work().
I think I've rejected that patch at least twice now :-) John's printk stuff will really land real soon now, right.