Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1456486

Re: [PACTH v1] kernel/hung_task.c: Dump all UNINTERUPTIBLE tasks

Show all headers | View raw

On 2016-08-04 09:22 AM, Tetsuo Handa wrote:
> Robert Foss wrote:
>> From: Aaron Durbin <adurbin@chromium.org>
>>
>> When the panic path is taken for khungtaskd dump all
>> tasks with the UNINTERUPTIBLE state. That way, any
>> inter-dependent tasks that caused one another to hang
>> will be saved in the crash output.
>
> How useful do you think this change is? If kdump is configured, you
> can obtain the same information from vmcore using crash utility. If
> kdump is not configured, it might be so in order to reboot as quick
> as possible using panic_timeout < 0.

The general idea is to provide more potentially helpful information 
since we have access to it.
kdump may or may not be configured on a system, but even without kdump 
we have access to this set of information, which me might as well supply 
to provide more information for figuring out the root cause of the hung 
task.

Having the information be available by default simplifies debugging when 
interacting with non-technical endusers.

>
> Also, from my experience, inter-dependent tasks are not always blocked
> in UNINTERUPTIBLE state. If they are AB-BA deadlock, this change will
> help only when they are waiting using unkillable version of wait
> primitives. I think most of simple AB-BA deadlocks are detected by
> lockdep and fixed by now. An example where kswapd is reported as a
> hung task ( http://lkml.kernel.org/r/20160211225929.GU14668@dastard ) is
> AB-BA deadlock which lockdep can't detect and inter-dependent tasks are
> not blocked for long in UNINTERUPTIBLE state.

If a task is blocking in a non-UNINTERUPTIBLE state this patch won't do 
anything, but this logging not catching all potential inter-dependency 
caused hangs, does not mean that the patch won't be helpful is some 
scenarios.

>
> Also, slide 18 of http://I-love.SAKURA.ne.jp/tomoyo/LCJ2014-en.pdf uses
> SystemTap to install a hook for SysRq-t when a hung task is reported.
> You will be able to run SysRq-w using it.
>
> I don't NACK this patch. But I think this patch could be conditional (e.g.
> show_state_filter(0) if sysctl_hung_task_panic == 2 and
> show_state_filter(TASK_UNINTERRUPTIBLE) if sysctl_hung_task_panic == 3)
> for environment where SystemTap can't be used.

That sounds like a good alternative to me, if the below snippet looks 
good to you, I'll submit it as v2.

         if (sysctl_hung_task_panic) {
+               if (sysctl_hung_task_panic == 2)
+                       show_state_filter(0);
+               else if (sysctl_hung_task_panic == 3)
+                       show_state_filter(TASK_UNINTERRUPTIBLE);
+
                 trigger_all_cpu_backtrace();


>
>>
>> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
>> Tested-by: Robert Foss <robert.foss@collabora.com>
>> Signed-off-by: Robert Foss <robert.foss@collabora.com>
>> ---
>>  kernel/hung_task.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
>> index d234022..946caf9 100644
>> --- a/kernel/hung_task.c
>> +++ b/kernel/hung_task.c
>> @@ -122,6 +122,8 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout)
>>  	touch_nmi_watchdog();
>>
>>  	if (sysctl_hung_task_panic) {
>> +		/* Dump all tasks. */
>> +		show_state_filter(TASK_UNINTERRUPTIBLE);
>>  		trigger_all_cpu_backtrace();
>>  		panic("hung_task: blocked tasks");
>>  	}
>> --
>> 2.7.4
>>
>>

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[PACTH v1] kernel/hung_task.c: Dump all UNINTERUPTIBLE tasks robert.foss@collabora.com - 2016-08-02 17:30 +0200
  Re: [PACTH v1] kernel/hung_task.c: Dump all UNINTERUPTIBLE tasks Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-08-04 15:30 +0200
    Re: [PACTH v1] kernel/hung_task.c: Dump all UNINTERUPTIBLE tasks Robert Foss <robert.foss@collabora.com> - 2016-08-04 17:40 +0200

csiph-web