From: Petr Mladek <pmladek@suse.com>
To: Lance Yang <lance.yang@linux.dev>
Cc: atomlin@atomlin.com, akpm@linux-foundation.org,
mhiramat@kernel.org, linux-kernel@vger.kernel.org,
david.laight.linux@gmail.com, neelx@suse.com, sean@ashe.io,
chjohnst@gmail.com, steve@abita.co, mproche@gmail.com,
nick.lange@gmail.com
Subject: Re: [PATCH v9 2/2] hung_task: Log summary line when warning budget is exhausted
Date: Wed, 26 Aug 2026 13:31:24 +0200 [thread overview]
Message-ID: <ao7OjHXyepmwaTr_@pathway.suse.cz> (raw)
In-Reply-To: <20260814162734.76714-1-lance.yang@linux.dev>
On Sat 2026-08-15 00:27:34, Lance Yang wrote:
>
> On Fri, Aug 14, 2026 at 09:57:18AM -0400, Aaron Tomlin wrote:
> >Once the warning budget is exhausted, hung_task_info() stops printing
> >per-task details. To provide visibility without causing additional log
> >spam, emit a single aggregate summary line at the end of each watchdog
> >scan when hung tasks are detected and the warning budget is exhausted.
> >
> >Keep per-task reports budgeted to avoid flooding dmesg or causing
> >ring buffer overflows during system-wide hangs.
>
> Hm... not quite unconditional. hung_task_call_panic still gets through
> budget gate, so with hung_task_warnings=1 and hung_task_panic=2, first
> task can exhaust budget and second one still gets full details (right
> before panic).
Great catch!
> I'd write changelog like this:
>
> Once the warning budget is exhausted, hung_task_info() normally stops
> printing per-task details. When panic is triggered, full details are
> still printed so diagnostics remain available before panic.
>
> To retain visibility without restoring per-task output after budget
> exhaustion, emit a single aggregate summary line at the end of each
> watchdog scan that detects hung tasks with an exhausted budget. This
> keeps non-panic per-task reports budgeted during system-wide hangs.
Yup, this sounds better.
> >--- a/kernel/hung_task.c
> >+++ b/kernel/hung_task.c
> >@@ -268,7 +268,7 @@ static void hung_task_info(struct task_struct *t, unsigned long timeout,
> > debug_show_blocker(t, timeout);
> >
> > if (!hung_task_warnings_printed)
> >- pr_info("Future hung task reports are suppressed, see sysctl kernel.hung_task_warnings\n");
> >+ pr_info("Future hung task reports won't print details about each process, see sysctl kernel.hung_task_warnings\n");
>
> Same exception here... next task can hit panic threshold and print full
> details anyway (and this line can be printed while hung_task_call_panic
> is already set).
>
> I'd make condition and message match actual behavior:
>
> "hung_task: further per-task details suppressed until warning budget is
> reset or panic is triggered (see sysctl kernel.hung_task_warnings)\n"
Looks better as well.
With the two changes:
Reviewed-by: Petr Mladek <pmladek@suse.com>
One more idea. It might be useful to print a message also
in first clean check after a stall was resolved.
But it might need to add one more variable, e.g.
last_round_count. We could not check
(hung_task_warnings_printed != READ_ONCE(sysctl_hung_task_warnings))
because it might be racy.
It might be done later in a separate patch.
Best Regards,
Petr
prev parent reply other threads:[~2026-08-26 11:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 13:57 [PATCH v9 0/2] hung_task: Improve warning budget handling and task reporting Aaron Tomlin
2026-08-14 13:57 ` [PATCH v9 1/2] hung_task: Reset warning budget when problem gets resolved Aaron Tomlin
2026-08-14 15:58 ` Lance Yang
2026-08-14 17:22 ` Aaron Tomlin
2026-08-26 11:17 ` Petr Mladek
2026-08-27 15:30 ` Lance Yang
2026-08-28 9:05 ` Petr Mladek
2026-08-28 9:22 ` Lance Yang
2026-08-14 13:57 ` [PATCH v9 2/2] hung_task: Log summary line when warning budget is exhausted Aaron Tomlin
2026-08-14 16:27 ` Lance Yang
2026-08-14 17:26 ` Aaron Tomlin
2026-08-26 11:31 ` Petr Mladek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ao7OjHXyepmwaTr_@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=atomlin@atomlin.com \
--cc=chjohnst@gmail.com \
--cc=david.laight.linux@gmail.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mproche@gmail.com \
--cc=neelx@suse.com \
--cc=nick.lange@gmail.com \
--cc=sean@ashe.io \
--cc=steve@abita.co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®