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 5C18B335554 for ; Wed, 28 Jan 2026 23:16:18 +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=1769642178; cv=none; b=u2rkyTDkOMouNtjeelOJ2bYlTVMCNzTgn7lgzmL0JFey2T+jH8gKuaxmcTa0xktaTIcpE8XSgM/o/QlUmsz/ej3Y2cfGJpcXRacBz2nO5aXob+ghsxdFFKhBJizJfGxzCq+qnS6xnJNlGod74Hx5maBLPkMpRq/iGFByjqaR+ls= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769642178; c=relaxed/simple; bh=wjjlhxmR/kzIvkJqm/Dly/SzSAvu1dcGeXQDxnSR/j8=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=kFZ7nyScLdcnn4O7WI8Zsa6gi9oht9hi08EXeupIkNc8MIp7jXH2GVWfJJLpQYxlxKh7bMyTKzUOJih2VcBdsYO6zRk4CbWNQOmhNgMlG075eO3X7Z5R2wDKASZkb09Rnlrl5NRYMJBRKecv+KqibEGkUS7nVhDyCau6vUhRQlQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n4pGzDIy; 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="n4pGzDIy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B30FC4CEF1; Wed, 28 Jan 2026 23:16:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769642178; bh=wjjlhxmR/kzIvkJqm/Dly/SzSAvu1dcGeXQDxnSR/j8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=n4pGzDIyrOacS2vq+rwz9sq2xvg7vqu33gunrpxL2S2rm5yClybwR9dIapbjM6IbF hJtaFSPrxDy9/AANHjTm6xywoZk/2Px5Zm723BhHJQqTGOV9rujpmxjY9XFKfTQmLW hkkeSTLsD4jHHA2BZFqmDKbAWqkEAnQmk1eiva3/vyMiLP76GAwFwS1Jvz8yAVg3Xa f7fZnzxveRJsLaaAnxG7CHXZs52MAt0glzvAVantqopWUcG7Wvw/ogqTLvPcGgnpFe 7m8UM3eBvsyKhmeyIwHMnPunBe5r5ktZnJrT0YeV9TnDqF5UMM83bPoCe0KQ4Yn3Aa JYBaPfthv4XVw== Date: Thu, 29 Jan 2026 08:16:14 +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: [v2 PATCH 1/1] hung_task: Explicitly report I/O wait state in log output Message-Id: <20260129081614.26b3bb8dc14d684e751f2c8c@kernel.org> In-Reply-To: <20260128204516.3473709-2-atomlin@atomlin.com> References: <20260128204516.3473709-1-atomlin@atomlin.com> <20260128204516.3473709-2-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 Wed, 28 Jan 2026 15:45:16 -0500 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. 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. > > Signed-off-by: Aaron Tomlin Looks good to me. Acked-by: Masami Hiramatsu (Google) Thanks, > --- > 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..abfbb5d9eeee 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 %s for more than %ld seconds.\n", > + t->comm, t->pid, t->in_iowait ? "in I/O wait" : "", > + (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)