linux-kernel - Re: [PATCH][v3] hung_task: Panic after fixed number of hung tasks

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: <aO4boXFaIb0_Wiif@pathway.suse.cz>
Date: Tue, 14 Oct 2025 11:45:05 +0200
From: Petr Mladek <pmladek@...e.com>
To: Lance Yang <lance.yang@...ux.dev>
Cc: lirongqing <lirongqing@...du.com>, wireguard@...ts.zx2c4.com,
	linux-arm-kernel@...ts.infradead.org,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>,
	linux-doc@...r.kernel.org, David Hildenbrand <david@...hat.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Stanislav Fomichev <sdf@...ichev.me>, linux-aspeed@...ts.ozlabs.org,
	Andrew Jeffery <andrew@...econstruct.com.au>,
	Joel Stanley <joel@....id.au>, Russell King <linux@...linux.org.uk>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Shuah Khan <shuah@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
	Jonathan Corbet <corbet@....net>,
	Joel Granados <joel.granados@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Phil Auld <pauld@...hat.com>, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Jakub Kicinski <kuba@...nel.org>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	Simon Horman <horms@...nel.org>,
	Anshuman Khandual <anshuman.khandual@....com>,
	Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
	Kees Cook <kees@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	"Paul E . McKenney" <paulmck@...nel.org>,
	Feng Tang <feng.tang@...ux.alibaba.com>,
	"Jason A . Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH][v3] hung_task: Panic after fixed number of hung tasks

On Tue 2025-10-14 13:23:58, Lance Yang wrote:
> Thanks for the patch!
> 
> I noticed the implementation panics only when N tasks are detected
> within a single scan, because total_hung_task is reset for each
> check_hung_uninterruptible_tasks() run.

Great catch!

Does it make sense?
Is is the intended behavior, please?

> So some suggestions to align the documentation with the code's
> behavior below :)

> On 2025/10/12 19:50, lirongqing wrote:
> > From: Li RongQing <lirongqing@...du.com>
> > 
> > Currently, when 'hung_task_panic' is enabled, the kernel panics
> > immediately upon detecting the first hung task. However, some hung
> > tasks are transient and the system can recover, while others are
> > persistent and may accumulate progressively.

My understanding is that this patch wanted to do:

   + report even temporary stalls
   + panic only when the stall was much longer and likely persistent

Which might make some sense. But the code does something else.

> > --- a/kernel/hung_task.c
> > +++ b/kernel/hung_task.c
> > @@ -229,9 +232,11 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout)
> >   	 */
> >   	sysctl_hung_task_detect_count++;
> > +	total_hung_task = sysctl_hung_task_detect_count - prev_detect_count;
> >   	trace_sched_process_hang(t);
> > -	if (sysctl_hung_task_panic) {
> > +	if (sysctl_hung_task_panic &&
> > +			(total_hung_task >= sysctl_hung_task_panic)) {
> >   		console_verbose();
> >   		hung_task_show_lock = true;
> >   		hung_task_call_panic = true;

I would expect that this patch added another counter, similar to
sysctl_hung_task_detect_count. It would be incremented only
once per check when a hung task was detected. And it would
be cleared (reset) when no hung task was found.

Best Regards,
Petr