From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (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 0B4EBEAE7 for ; Wed, 28 Jan 2026 08:26:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769588793; cv=none; b=Z+niNwcwC9HcImS3huDnpHafUhIsVoVpDmudJCH/vCUuEWPBzQ8BGjSo1rb9lZfI/6AlEN+9Qkx5vhriY0yTugN+/QKFbUeXSvi8LSxlKG65MkDLnj0WsKfqk6xrqZrQulPlsVNlJAfOCI8yJfHOZvNb9qF/ZaVClSGMAq4A+MQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769588793; c=relaxed/simple; bh=V75Kz/SBnewefEgA+VXUIh5FWTsF9+WDboW6RD0Zp9Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aj3ixwqQ58YPUNKBILWgc/neuUbiKyD1h2Yyroj7zGNudYOscpaLViDRfF5bgOzGxFn0B+QX5rbbdVSMNoNB7M5ke/4rHR4SzFsX6Bzaxfalj47nHWsdbvobiGHooNI7Nj4wSAIiiwyCW9zKiEQNsKd7wNFmg6MemirJ+F4JNAA= 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=bkzooDnP; arc=none smtp.client-ip=91.218.175.181 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="bkzooDnP" Message-ID: <5eec3a75-43e5-4bfd-a303-a89f5d121be6@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1769588789; 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=Q/aJhggtIl4ssJzXzbNr8xt63gdYHH/bQ6Vco7dLW2Q=; b=bkzooDnP7WC1UdbFXtzFUoH6XN2WTWXvR6lA5KgMZuNFCxKDZUqmGpOJ+QuODjfiQq5ql1 /BnmLLca6dVAOcutJuItt5Ok9cPQMdQM7vMj/FEJ65uAUcXkJtW3LrlXXPCmZY6L5Meti/ KL5mzuCHPX1pg+hxl3Zn4KYkIZvn43g= Date: Wed, 28 Jan 2026 16:26:21 +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: "Masami Hiramatsu (Google)" , Aaron Tomlin Cc: akpm@linux-foundation.org, 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 References: <20260125203905.3393869-1-atomlin@atomlin.com> <20260128171749.f46ee8511deebe034b11171b@kernel.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <20260128171749.f46ee8511deebe034b11171b@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/1/28 16:17, Masami Hiramatsu (Google) wrote: > 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" : ""); That would be better, looks good to me ;)