Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1544979
| From | Vegard Nossum <vegard.nossum@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] locking/hung_task: Defer showing held locks |
| Date | 2016-12-20 09:20 +0100 |
| Message-ID | <sQnOp-33L-13@gated-at.bofh.it> (permalink) |
| References | <sNWyZ-2mS-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 13 December 2016 at 15:45, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> 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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] locking/hung_task: Defer showing held locks Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-12-13 15:50 +0100
Re: [PATCH] locking/hung_task: Defer showing held locks Vegard Nossum <vegard.nossum@gmail.com> - 2016-12-20 09:20 +0100
Re: [PATCH] locking/hung_task: Defer showing held locks Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-12-20 14:40 +0100
csiph-web