On (03/02/16 11:30), Petr Mladek wrote:
On Thu 2016-02-25 14:10:05, Sergey Senozhatsky wrote:
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
I was curious why your patch actually did not help to avoid the
softlockup. The infinite printk loop was called in a safe context,
CONFIG_PREEMPT_COUNT=y, so it did set console_may_schedule = 1.
But it never got console_sem, never called console_unlock()
and never called cond_resched() there. So, it never got preempted
in the PREEMPT_NONE kernel. The console_sem was owned by
another process that was busy handling the flood of messages.
Note that the infinite cycle calling printk() might be interrupted anywhere
by the NMI watchdog. It explains why the original report pointed
at the beginning of the printk. It was not a deadlock.
I got the softlockup on random locations here.
Also it is not the classic softlockup in console_unlock().
The process handling the console actually could sleep if it
has console_may_schedule = 1. This is why console_unlock()
did not appeared in the softlockup backtrace.
Sergey is correct and his patches are innocent here.
thank you, Petr!
Sergey, if you send the fix for
of_unittest_destroy_tracked_overlays(), please add me into CC.
of course, will try to send it out tonight.
PS: I am sorry for the noise and that it took me so long to shake my
head around this problem. Thanks a lot for patience.
no problem at all. thank you. the more we double check it - the better.