From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) (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 AFD8E1DDC07 for ; Mon, 26 Jan 2026 02:30:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769394632; cv=none; b=sJ987PXSJvatzVPTRVd5V3RVT8wj6MG8tJaHoQzZNRc4D/HBnSUnrFgIAU1tJC0MmkuuuBeUecHO3DOcbY0/SirSHBMrrq3mtJCTNpVb7Atcr5VDqdHZBUAIJjH3IJr9QYUkRr4Wpiqgsjh0l7R97b7+tVkiZd4/SMA/2hEqUrU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769394632; c=relaxed/simple; bh=0paLL2ZjdnomPt/ZyPKEdA+IZB2Vh6lqOzdWZgXvT7s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lbbjj3rHDIax2CVQmWivEcGJLk2TpFvheJZbtgt+6blMZk7N+APuBooZgnXj/yIGjsunvFSRDsG97mWKDRzwFXdknmVTzhKfSKYl1ZjP5pdVy3lDZG4HeynZEpaBsIw9PWMWHSlQO32x/0puYUwAVw7+BJXzWgR3+vg3dcuw+eA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=vzunry9/; arc=none smtp.client-ip=95.215.58.186 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="vzunry9/" Message-ID: <79da6790-b972-417b-8004-bfb4084af82a@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1769394628; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gAC/8CFNGOPileotcbrKsYURMJWxlprUfL15uLsTQ/M=; b=vzunry9/CIlbe+ipZDZdRoOmebllvHrtRA+S5/CkOAsYpARii386Tdutyqm828PvT2apft 7gjZ7Ze9M3I+DshA0zPfbnYRS7suAK7eAc1zS3afTz1aNqB8Ij+7nHB3X4H6hhXQPnH98i H/ikD8ztIEZkwjk2bdbeYtQIyp3IWlY= Date: Mon, 26 Jan 2026 10:30:22 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] hung_task: Differentiate between I/O and Lock/Resource waits Content-Language: en-US To: Aaron Tomlin Cc: neelx@suse.com, sean@ashe.io, pmladek@suse.com, gregkh@linuxfoundation.org, joel.granados@kernel.org, mproche@gmail.com, chjohnst@gmail.com, nick.lange@gmail.com, linux-kernel@vger.kernel.org, mhiramat@kernel.org, akpm@linux-foundation.org References: <20260125203905.3393869-1-atomlin@atomlin.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <20260125203905.3393869-1-atomlin@atomlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/1/26 04:39, 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)", > + (jiffies - t->last_switch_time) / HZ); > pr_err(" %s %s %.*s\n", > print_tainted(), init_utsname()->release, > (int)strcspn(init_utsname()->version, " "), Why do we need this? It's rather obvious that the stack trace already shows whether it is in "D (Disk I/O)" or "D (Lock/Resource)" or "D (...)".