From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24C7C274B51 for ; Wed, 28 Jan 2026 08:17:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769588273; cv=none; b=SyjRSJu04C8mlKjX0ZZEG1Wqf8pBQgOV49kRRv9qwTYAQ3tnUoaNptJyLY6xsD1a9b7c/IaWQDQGlp96/1gRuC0FD/9nYvGzQIw9PAJ4CHUNJwVn95Fiodn/phpOUeH7RZjUzaJ3t9zhESCpBuufmiDT8JD7RvxsJULzgo+Y6WY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769588273; c=relaxed/simple; bh=ntW/ad+mLVIjWRX2eNt8ySjPjYCJ/IspDrlEqMVmurk=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=Jur3PcByhgNM36675/uXNzbTSFWHZ/hWB8EVF2US+aU8ln2MPKcf5yihpTLOlS9/wjj2aq7qQIV5WowYwqnXIHhR0q+jqugD2tIyHGozccejzdIneCnyGhLu6gXbqGOWK5dbHfFqrHq7MAHw70Zvzi+PJBGwQN3YqZO1jQaWAZo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OI6hk6ms; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OI6hk6ms" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A6A6C16AAE; Wed, 28 Jan 2026 08:17:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769588272; bh=ntW/ad+mLVIjWRX2eNt8ySjPjYCJ/IspDrlEqMVmurk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OI6hk6ms9AeReOkYAW3QmgxZ8kSUL9e7ah8YDz3nF/b5+BHoBS0CILr71Iofy/M33 Q8xHqX6DLsYsy/AlC0OT9NjuAe6PYSbjkyn28tH7mX+KV031AR2ahI8niLiKMCbmcv jktNMfAL1I7zg3/qYhGYChUkXlFRcP9oRGlabRihBKwC6nEDGQE4TJG+oHF0OqGwBa jCfXTtVHrOVYReLLNfdvWJZp2Nq8MEhBbOY7nuc2/JhJNE4hh8j1bmV6WhGdrmGw6l i7bpww+/xNRRJQf5rIvLplEt6DIJoVWSYXPgqcfLlZASZ/lyIoFcRYYpIiV0cr2vB9 87FUGLo0kWfRw== Date: Wed, 28 Jan 2026 17:17:49 +0900 From: Masami Hiramatsu (Google) To: Aaron Tomlin Cc: akpm@linux-foundation.org, lance.yang@linux.dev, gregkh@linuxfoundation.org, pmladek@suse.com, 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: [PATCH] hung_task: Differentiate between I/O and Lock/Resource waits Message-Id: <20260128171749.f46ee8511deebe034b11171b@kernel.org> In-Reply-To: <20260125203905.3393869-1-atomlin@atomlin.com> References: <20260125203905.3393869-1-atomlin@atomlin.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 25 Jan 2026 15:39:05 -0500 Aaron Tomlin wrote: > Currently, the hung task reporting mechanism does not differentiate > between the underlying causes of a D state, labelling all such tasks > merely as "blocked". Consequently, administrators must perform manual > stack trace inspection to ascertain if the delay stems from an I/O wait > (indicative of hardware or filesystem issues) or a lock wait (indicative > of software contention). > > This change utilises the in_iowait field from struct task_struct to > distinguish between two distinct failure modes in the log output: > > 1. D state "Disk I/O": The task is waiting in io_schedule(). > This typically implies a storage device, filesystem, or > network filesystem (e.g., NFS) is unresponsive. > > 2. D state "Lock/Resource": The task is waiting on a kernel > primitive (e.g., mutex). This typically implies a software > bug, deadlock, or resource starvation. > > It is safe to read in_iowait in this manner because > check_hung_uninterruptible_tasks() holds the RCU read lock, preserving > the task structure. Moreover, the task is effectively quiescent (in a > persistent TASK_UNINTERRUPTIBLE state) and thus cannot update its own > in_iowait status, guaranteeing a stable, race-free value. > > Signed-off-by: Aaron Tomlin > --- > 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 350093de0535..608731c7ccba 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 in %s state for more than %ld seconds.\n", > + t->comm, t->pid, t->in_iowait ? "D (Disk I/O)" : "D (Lock/Resource)", If this is only for human readability, I rather like just adding "in iowait" at the end. "D" state seems redundant, and "Lock/Resource" can mislead. What about something like below? pr_err("INFO: task %s:%d blocked for more than %ld seconds%s.\n", ..., t->in_iowait ? " in I/O wait" : ""); Thank you, > + (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 > -- Masami Hiramatsu (Google)