On 13 December 2016 at 15:45, Tetsuo Handa <[email protected]> wrote: > When I was running my testcase which may block hundreds of threads > on fs locks, I got lockup due to output from debug_show_all_locks() > added by commit b2d4c2edb2e4f89a ("locking/hung_task: Show all locks"). > > I think we don't need to call debug_show_all_locks() on each blocked > thread. Let's defer calling debug_show_all_locks() till before panic() > or leaving for_each_process_thread() loop.
First of all, sorry for not answering earlier. I'm not sure I fully understand the problem, you say the "output from debug_show_all_locks()" caused a lockup, but was the problem simply that the amount of output caused it to stall for a long time? Could we instead 1) move the debug_show_all_locks() into the if (sysctl_hung_task_panic) bit unconditionally 2) call something (touch_nmi_watchdog()?) inside debug_show_all_locks() 3) in another way make debug_show_all_locks() more robust so it doesn't "lockup" ? Vegard
