From: Aaron Tomlin <atomlin@atomlin.com>
To: akpm@linux-foundation.org, lance.yang@linux.dev,
mhiramat@kernel.org, gregkh@linuxfoundation.org,
pmladek@suse.com
Cc: neelx@suse.com, sean@ashe.io, mproche@gmail.com,
chjohnst@gmail.com, nick.lange@gmail.com, da.anzani@gmail.com,
linux-kernel@vger.kernel.org
Subject: [PATCH v4] hung_task: Explicitly report I/O wait state in log output
Date: Tue, 3 Mar 2026 17:13:24 -0500 [thread overview]
Message-ID: <20260303221324.4106917-1-atomlin@atomlin.com> (raw)
Currently, the hung task reporting mechanism indiscriminately labels all
TASK_UNINTERRUPTIBLE (D) tasks as "blocked", irrespective of whether they
are awaiting I/O completion or kernel locking primitives. This ambiguity
compels system administrators to manually inspect stack traces to discern
whether the delay stems from an I/O wait (typically indicative of
hardware or filesystem anomalies) or software contention. Such detailed
analysis is not always immediately accessible to system administrators
or support engineers.
To address this, this patch utilises the existing in_iowait field within
struct task_struct to augment the failure report. If the task is blocked
due to I/O (e.g., via io_schedule_prepare()), the log message is updated
to explicitly state "blocked in I/O wait".
Examples:
- Standard Block: "INFO: task bash:123 blocked for more than 120
seconds".
- I/O Block: "INFO: task dd:456 blocked in I/O wait for more than
120 seconds".
Theoretically, concurrent executions of io_schedule_finish() could
result in a race condition where the read flag does not precisely
correlate with the subsequently printed backtrace. However, this
limitation is deemed acceptable in practice. The entire reporting
mechanism is inherently racy by design; nevertheless, it remains highly
reliable in the vast majority of cases, particularly because it
primarily captures protracted stalls. Consequently, introducing
additional synchronisation to mitigate this minor inaccuracy would be
entirely disproportionate to the situation.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Changes since v3 [1]:
- Added Reviewed-by: tag from Petr Mladek
- Included a more authentic description of the race condition,
notwithstanding khungtaskd by design (Petr Mladek)
Changes since v2 [2]:
- Added Acked-by: from Masami Hiramatsu
Changes since v1 [3]:
- Provided a more descriptive message (Masami Hiramatsu)
[1]: https://lore.kernel.org/lkml/20260208002458.3791059-1-atomlin@atomlin.com/
[2]: https://lore.kernel.org/lkml/20260128204516.3473709-2-atomlin@atomlin.com/
[3]: https://lore.kernel.org/lkml/20260125203905.3393869-1-atomlin@atomlin.com/
kernel/hung_task.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index 8bc043fbe89c..6fcc94ce4ca9 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -250,8 +250,9 @@ static void hung_task_info(struct task_struct *t, unsigned long timeout,
if (sysctl_hung_task_warnings || hung_task_call_panic) {
if (sysctl_hung_task_warnings > 0)
sysctl_hung_task_warnings--;
- pr_err("INFO: task %s:%d blocked for more than %ld seconds.\n",
- t->comm, t->pid, (jiffies - t->last_switch_time) / HZ);
+ pr_err("INFO: task %s:%d blocked%s for more than %ld seconds.\n",
+ t->comm, t->pid, t->in_iowait ? " in I/O wait" : "",
+ (jiffies - t->last_switch_time) / HZ);
pr_err(" %s %s %.*s\n",
print_tainted(), init_utsname()->release,
(int)strcspn(init_utsname()->version, " "),
--
2.51.0
reply other threads:[~2026-03-03 22:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260303221324.4106917-1-atomlin@atomlin.com \
--to=atomlin@atomlin.com \
--cc=akpm@linux-foundation.org \
--cc=chjohnst@gmail.com \
--cc=da.anzani@gmail.com \
--cc=gregkh@linuxfoundation.org \
--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=pmladek@suse.com \
--cc=sean@ashe.io \
/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