From: Petr Mladek <pmladek@suse.com>
To: Aaron Tomlin <atomlin@atomlin.com>
Cc: akpm@linux-foundation.org, lance.yang@linux.dev,
mhiramat@kernel.org, gregkh@linuxfoundation.org,
joel.granados@kernel.org, neelx@suse.com, sean@ashe.io,
mproche@gmail.com, chjohnst@gmail.com, nick.lange@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [v2 PATCH 1/1] hung_task: Explicitly report I/O wait state in log output
Date: Mon, 2 Feb 2026 16:14:42 +0100 [thread overview]
Message-ID: <aYC_Yr6SQVTUkyV6@pathway> (raw)
In-Reply-To: <20260128204516.3473709-2-atomlin@atomlin.com>
On Wed 2026-01-28 15:45:16, Aaron Tomlin wrote:
> 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".
>
> Accessing in_iowait is safe in this context. The detector holds
> rcu_read_lock() within check_hung_uninterruptible_tasks(), ensuring the
> task structure remains valid in memory.
This part is true.
> Furthermore, as the task is
> confirmed to be in a persistent TASK_UNINTERRUPTIBLE state, it cannot
> modify its own in_iowait flag, rendering the read operation stable and
> free from data races.
Strictly speaking, this is not true. IMHO, nothing prevents the task
from waking up in parallel. Just the chance is small.
I would say that the information will be valid in 99.99% of situations
because the message is printed only when the task has been stuck
in the state for a long time. A possible mistake should be
visible from the later printed backtrace.
> --- 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",
s/blocked %s for/blocked%s for/
> + t->comm, t->pid, t->in_iowait ? "in I/O wait" : "",
and here: " in I/O wait".
Otherwise, it would print two spaces in the non-io case, like"
"INFO: task bash:123 blocked for more than 120 seconds"
> + (jiffies - t->last_switch_time) / HZ);
> pr_err(" %s %s %.*s\n",
> print_tainted(), init_utsname()->release,
> (int)strcspn(init_utsname()->version, " "),
Otherwise, it looks good.
Best Regards,
Petr
next prev parent reply other threads:[~2026-02-02 15:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 20:45 [v2 PATCH 0/1] hung_task: Explicitly report I/O wait state in log output Aaron Tomlin
2026-01-28 20:45 ` [v2 PATCH 1/1] " Aaron Tomlin
2026-01-28 23:16 ` Masami Hiramatsu
2026-02-03 1:32 ` Aaron Tomlin
2026-02-02 15:14 ` Petr Mladek [this message]
2026-02-02 15:28 ` Lance Yang
2026-02-03 1:24 ` Aaron Tomlin
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=aYC_Yr6SQVTUkyV6@pathway \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=atomlin@atomlin.com \
--cc=chjohnst@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=joel.granados@kernel.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.