[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77864d48-ce55-a699-ee6e-60d9ec36e305@i-love.sakura.ne.jp>
Date: Tue, 11 Dec 2018 19:02:07 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: "Liu, Chuansheng" <chuansheng.liu@...el.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"pmladek@...e.com" <pmladek@...e.com>,
"sergey.senozhatsky@...il.com" <sergey.senozhatsky@...il.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"dvyukov@...gle.com" <dvyukov@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel/hung_task.c: force ignore_loglevel before panic
On 2018/12/11 10:16, Liu, Chuansheng wrote:
> We may enhance it by:
> - if (sysctl_hung_task_warnings) {
> + if (sysctl_hung_task_panic || sysctl_hung_task_warnings) {
> if (sysctl_hung_task_warnings > 0)
> sysctl_hung_task_warnings--;
Why ignore sysctl_hung_task_warnings? The administrator can already
configure as sysctl_hung_task_warnings == -1 && sysctl_hung_task_panic == 1
if he/she does not want to suppress neither sched_show_task() nor
debug_show_all_locks()/trigger_all_cpu_backtrace(). Someone might want
that sysctl_hung_task_warnings == 0 (which is a request to suppress only
sched_show_task()) should not be ignored by sysctl_hung_task_panic == 1
(which is a request to trigger panic).
Powered by blists - more mailing lists