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

[Aaron Tomlin]

On Tue, Jul 21, 2026 at 03:28:48PM +0200, Petr Mladek wrote:
> > 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, ...

Hi Petr,

Thank you for the detailed review and for taking the time to draft these
patches. I completely agree with your assessment; in my attempt to cover
every edge case of lock contention, the v6 implementation became
too entangled within check_hung_uninterruptible_tasks().

Your approach in these two patches is much more elegant. Decoupling the
active warning budget from the configured sysctl limit perfectly solves the
permanent blind spot, and ensuring the basic one-line report always prints
provides sufficient visibility without the risk of massive stack-dump log
bloat.

I will happily concede.

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

I do think this is worth doing to prevent the single-line spam if a task
remains hung for hours, no?


Kind regards,
-- 
Aaron Tomlin