On 2022-02-15, Daniel Bristot de Oliveira <bristot@xxxxxxxxxx> wrote: > I am aware of printk_deferred(), and every once and while I am Cc'ed > on patches suggesting changing printk() to printk_deferred(), but they > are not, let's say, welcome [1]... that is why I am not using it. Yes. printk_deferred() is a workaround until we can get printk "PROVE_RAW_LOCK_NESTING clean". But currently there is real deadlock potential in the kernel with printk. For the most common cases, we use printk_deferred() to get around it. Once printk() is clean, we can replace all printk_deferred() call sites with printk(). I haven't looked into the details of your runtime verification method, but I assume it digs deep into some interfaces. In that case, the deadlock potential of printk may be relatively high. (And indeed, you have seen some.) IMHO, before warning users not to use this reactor if locks XYZ are taken, it would be better just to use printk_deferred() and it will always log without causing problems to the system you are trying to verify. > I saw deadlocks in the past, and while testing the WIP monitor some > time ago, it seems it depends on the console type. If such restriction > does not exist anymore, I can remove that comment, it would be even > better! If you say it depended on the console type, then it was probably the framebuffer console that was at fault. The fbcon is a landmine for deadlocks, which is why PREEMPT_RT avoids fbcon printing from non-preemptible context. For mainline, the series is currently in review. Perhaps avoiding fbcon would be good enough for you to avoid deadlocks with this reactor using printk(). John > [1] https://lore.kernel.org/lkml/e68888438cec9a1da53aaa1647720ade638d6ad4.1600705105.git.bristot@xxxxxxxxxx/
