Re: [PATCH v6] hung_task: Deduplicate identical hang reports using explicit blocker tracking

[Lance Yang <lance.yang@linux.dev>]

On Tue, Jul 21, 2026 at 03:28:48PM +0200, Petr Mladek wrote:
>On Tue 2026-07-21 13:08:32, Lance Yang wrote:
>> 
>> On Sun, Jul 19, 2026 at 12:13:05PM -0400, Aaron Tomlin wrote:
[...]
>> 
>> Sorry for the late reply.
>
>Don't worry. IMHO, a reply within one week is perfectly
>fine. Sometimes even this is not possible.

Cheers!

>> Still, v6 looks far too complicated ... and touches too much core code
>> for the problem you're trying to address ...
>
>I agree that it looks too complicated. I see several problems:
>
>  1. Many changes are added in a single patch. I suggest to split
>     it next time into more patches and add the features from
>     the most important one, ...
>
>  2. The code seems to be a bit over-engineered. There are too many
>     variables hung_task_blockers_count, hung_task_has_active,
>     warnings_decremented, skip_show_task, scan_completed,
>     did_report, seen_blockers_mask, ... I believe that it might
>     be done an easier way.
>
>  3. Too much spaghetti code is added to the already large
>     check_hung_uninterruptible_tasks() function. It might look
>     better when the detection of the duplicated task is handled
>     in a separate function, ...

v6 kinda snowballed :) Way too much state for what it buys us :)

>
>> Looked at this again ... Petr's earlier breakdown[1] makes sense. Both
>> problems are real:
>> 
>> "
>> I would split this into two problems:
>> 
>> 1. A single lock contention might trigger hung_report for many tasks
>>    waiting for the same lock. It bloats the kernel log and messages
>>    might even get lost.
>> 
>> 2. The number of printed backtraces can be reduced by a global limit.
>>    But the limit silences the hung task detector and system
>>    administrators are blind once the limit is reached.
>> "
>> 
>> IMO, that's the tradeoff: keep log noise down without leaving users
>> blind for good once budget runs out ...
>> 
>> Still not sold on dedup, though. Sure, duplicate reports happen, but how
>> often, really? Doesn't seem common enough to need this much code :)
>> 
>> If we really want to handle this in kernel, how about a simple mode
>> switch for hung_task_warnings?
>> 
>>   0 = keep the current global budget
>>   1 = allow up to hung_task_warnings reports in each scan
>
>Honestly, I do not think that this is the right way to go. The more I think
>about it, the more I believe that the global budget is simply wrong.
>
>IMHO, we should do the following:
>
>1. Reset the global budget when the situation is resolved and
>   there is no hung task any longer.
>
>2. The global budget should limit only printing all the details,
>   especially backtraces. We should always print at least
>   the task name, ...

Yeah, sounds better than another mode. Slight semantic change, but looks
fine to me.

>3. We could prevent printing the same process again and again
>   by adding "hung_task_reported" into struct task_struct.
>
>   But then we should print some summary about how many hung tasks
>   were found in the last round at least. So that we know that
>   the problem persists.
>
>   This should still be rather easy. But I am not sure if it is
>   worth it.

With 1 and 2 in place, don't think this is needed anymore ;)

>4. We could add the filtering of the duplicated backtraces. But
>   it has to be handled by some helper function.
>
>   It looks like to most complicated part. I would personally skip
>   it for now. We could always add it later when the above proposed
>   changes are not enough to tune the kernel.hung_task_warnings
>   value in the real life.

And blocker dedup gets even messier. Haven't seen a simple way to do
that. Happy to skip it :D

>
>
>I tried to implement the 1st and 2nd change using gemini just to
>see how it would look. And it looks good to me:

I really like this approach :)

Hope v7 sticks to these two changes; think that's all we need :)

[...]

Cheers, Lance