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: <bbdc2b5c2b374ed1801113148a72d83c@baidu.com>
Date: Tue, 23 Sep 2025 05:22:23 +0000
From: "Li,Rongqing" <lirongqing@...du.com>
To: Lance Yang <lance.yang@...ux.dev>, 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

> > 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.


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