linux-kernel - Re: [PATCH v3] hung_task: Explicitly report I/O wait state in log output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYmzg1OQaAuMb4n6@pathway.suse.cz>
Date: Mon, 9 Feb 2026 11:14:27 +0100
From: Petr Mladek <pmladek@...e.com>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: akpm@...ux-foundation.org, lance.yang@...ux.dev, mhiramat@...nel.org,
	gregkh@...uxfoundation.org, neelx@...e.com, sean@...e.io,
	mproche@...il.com, chjohnst@...il.com, nick.lange@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] hung_task: Explicitly report I/O wait state in log
 output

On Sat 2026-02-07 19:24:58, 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 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.

IMHO, this is not true. The blocked tasks might wake up at any time.
There is a small chance to print an inconsistent information.
But we could live with it. The entire hung task report is racy.

The race would actually be a lucky moment where the task get
unblocked. In this case, it won't be reported in the next
round...

I suggest to omit the entire paragraph.

> Acked-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>
> Signed-off-by: Aaron Tomlin <atomlin@...mlin.com>

Othrewise, it looks good.

With the removed paragraph:

Reviewed-by: Petr Mladek <pmladek@...e.com>

Best Regards,
Petr