Re: [v2 PATCH 1/1] hung_task: Explicitly report I/O wait state in log output

[Aaron Tomlin]

On Mon, Feb 02, 2026 at 04:14:42PM +0100, Petr Mladek wrote:
> > 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.

Hi Petr,

Thank you for the review and the keen eye on the formatting.

You are entirely correct regarding the potential race; claiming the value
is strictly "stable" was imprecise. I have updated the commit message to
reflect that this is a diagnostic snapshot.

I also agree that we should not attempt to strictly prevent this race.

Theoretically, io_schedule_finish() could be called immediately after
"khungtaskd" checks the flag, rendering the output stale. However, strictly
preventing this would require blocking the waking task (e.g., within the
mutex unlock code path - see mutex_lock_io()) to inhibit the state change
during the scan. This seems entirely disproportionate for a "best effort"
diagnostic tool, especially given the probability of such a race is
negligible after a long hang, by default.

I have also adjusted the pr_err() format string to eliminate the potential
double space in the non-I/O case.

> Otherwise, it looks good.


Kind Regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature