RE: [外部邮件] Re: [PATCH][v2] hung_task: Panic after fixed number of hung tasks

["Li,Rongqing" <lirongqing@baidu.com>]

> 
> 
> > On October 10, 2025 5:25:05 PM PDT, Randy Dunlap
> > <rdunlap@infradead.org>
> > wrote:
> > >Hi,
> > >
> > >On 9/27/25 10:31 PM, lirongqing wrote:
> > >> From: Li RongQing <lirongqing@baidu.com>
> > >>
> > >> 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
>