linux-kernel - Re: [外部邮件] Re: [PATCH][RFC] hung_task: Support to panic when the maximum number of hung task warnings is reached

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <06facb7b-7d1b-44fd-b530-9a5300db7d4c@linux.dev>
Date: Tue, 23 Sep 2025 13:55:20 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: "Li,Rongqing" <lirongqing@...du.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: "corbet@....net" <corbet@....net>,
 "mhiramat@...nel.org" <mhiramat@...nel.org>,
 "paulmck@...nel.org" <paulmck@...nel.org>,
 "pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
 "mingo@...nel.org" <mingo@...nel.org>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "rostedt@...dmis.org" <rostedt@...dmis.org>,
 "kees@...nel.org" <kees@...nel.org>, "arnd@...db.de" <arnd@...db.de>,
 "feng.tang@...ux.alibaba.com" <feng.tang@...ux.alibaba.com>,
 "pauld@...hat.com" <pauld@...hat.com>,
 "joel.granados@...nel.org" <joel.granados@...nel.org>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [外部邮件] Re: [PATCH][RFC] hung_task: Support to panic when the maximum number of hung task warnings is reached



On 2025/9/23 13:22, Li,Rongqing wrote:
>>> I assume the same argument applies to the NMI watchdog, to the
>>> softlockup detector and to the RCU stall detector?
>>>
>>> A general framework to handle all of these might be better.  But why
>>> do it in kernel at all?  What about a userspace detector which parses
>>> kernel logs (or new procfs counters) and makes such decisions?
>>
>> +1. I agree that a userspace detector seems more appropriate for this.
>>
> 
> I think the user-space maybe flexibility, but incurs relatively higher overhead and is less reliable. When the system hangs, this task may have already hung as well.

Emmm... if the system is so degraded that a userspace monitor cannot get
scheduled, it's very likely that khungtaskd itself is also struggling to
run, right?

> 
> 
>> We already have the hung_task_detect_count counter, so a userspace detector
>> could easily use that to implement custom policies ;)