RE: [外部邮件] Re: [PATCH][v2] hung_task: Panic after fixed number of hung tasks
From: Li,Rongqing
Date: Sat Oct 11 2025 - 20:00:03 EST
>
>
> > On October 10, 2025 5:25:05 PM PDT, Randy Dunlap
> > <rdunlap@xxxxxxxxxxxxx>
> > wrote:
> > >Hi,
> > >
> > >On 9/27/25 10:31 PM, lirongqing wrote:
> > >> From: Li RongQing <lirongqing@xxxxxxxxx>
> > >>
> > >> Currently, when hung_task_panic is enabled, kernel will panic
> > >> immediately upon detecting the first hung task. However, some hung
> > >> tasks are transient and the system can recover fully, while others
> > >> are unrecoverable and trigger consecutive hung task reports, and a
> > >> panic is
> > expected.
> > >>
> > >> This commit adds a new sysctl parameter hung_task_count_to_panic to
> > >> allows specifying the number of consecutive hung tasks that must be
> > >> detected
> >
> > Why make a new sysctl? Can't you just use hung_task_panic and raise
> > the max to INT_MAX?
> >
>
Sorry, I misunderstand at first.
I'm not sure if this sysctl hung_task_panic can be modified, and if changed, BOOTPARAM_HUNG_TASK_PANIC should be changed, and whether both changing will cause issues for users ?
If no one objects, I will reuse hung_task_panic , and not adding a new sysctl
Thanks
-Li
>
> However, this will prevent the printing of hung task warnings. Hung task
> warnings are very useful for identifying which tasks are hanging and where
> they are stuck.
>
> If there is this function, I hope to shorten sysctl_hung_task_timeout_secs to
> give more information.
>
> And rcu has the similar function as dfe564045c653d "(rcu: Panic after fixed
> number of stalls)"
>
> -Li
>