From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BF57378830 for ; Mon, 2 Feb 2026 15:14:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770045288; cv=none; b=BVBeA4kRecwXTMCyCmdXyDbayMMTsODWttMOomEMUMH+XcsZsQC21I8O6hpUYIVl5sbXxxcJ2a/bYwZSnzJytwoFUl6o34ZJBl2MXhnbyhiGK5GHX6D5OMFLM+a/iaGBj3TNVlclCCa+DA40yvMl+wK9U8wQg//4YF4KQBZydBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770045288; c=relaxed/simple; bh=oK1y7TOZeaWtnaR9aSzSD2t65HsX5Vp7nlCjyXiXsMg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lRvNSxoJEHx79tVksEuehsCwoBI6lpHd7kVG3Vfv82DPt2j9VSRjwXSfrr4nQ9RzFCl85S9Wh54gVCdWPoZvfij98GVJbhkXJsz6ztKEpvrzJhC0gSGjPfwwLZQavSAHuyUWtXUK+bbJJwgrOEzQ9nw8IIJO2lnDgPCvoeKrohw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=evQZuyaT; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="evQZuyaT" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso41962785e9.1 for ; Mon, 02 Feb 2026 07:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1770045285; x=1770650085; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Fu2aQcFYdTnPP8UCkbRi8OilV2iBlqbH6FvZAKUV+kc=; b=evQZuyaTikmhDWdMOCsw0CDA15bZrOwFKpy6GtTKIZBhXvTtmir4udPgR9Qjl7N8BG S7dnfdwsZKgJ++RJdp1mQ4cgEqczIkHyfkTg0yv189jCH4bMuuQz6Cp8bko21W8h0jUI 3KFI4WUF3F+11IGE8mMNS6lEzduadQcXB/ZsN3k3VQqRsuRb9YRnuVP3sThSIco9O2uU miSXGtkCoI94DQItHt+5mDOzoa27HpNf9D1n+1jfpVq9Ob4GxTIAySi1NiniWabGfzbZ +OFOZQVIjShqIPdcy8cqrtVL8YV8JV0nQIrrve01RYFinZM4PZIQ1wIHJO1uJtcoeLbk p87g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770045285; x=1770650085; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Fu2aQcFYdTnPP8UCkbRi8OilV2iBlqbH6FvZAKUV+kc=; b=piP/gfRLz0q0CXRwEHiwAQhedh1kL205oFUpVWnyx8KcShXXbTigxG+c2L48PE7wNZ xjrh+Uxt4n7JZVQRQjozQV1OJXTFM3dlppFtvOAlaVoGMV9zL7toeMJ3Jn6iWfHSYpM8 gINBNFm+QQvPRqKO3J1jI5Dltow6uNH2rPZiOdlh9QZwYQzyCV+k/eltnYfwshaF4xb+ TTXcyVTPrLRRDltbPsVRUTzQ91uiQILvcsJqJIFGkz3ubYjdKdUwOwgr8U1CYfEluxdq AqVR+YLw48p4rMY9ZejgQ0gB83JK1B/fV45s/MTmG3LwCugAfwqokCfkC5l2Xy+qyMy6 zLuQ== X-Forwarded-Encrypted: i=1; AJvYcCXbKDhh/idsqo0Vv3Ste9RWGHN7jkBvpMBkjek2GYJ0PNkANaly2i/sFiML8dfKFrMXwTlx2VB7752FGyg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5wHlIyqtxACJBZnwufyFQmeSesVHaR7aDDhSin2XjJPbyCnSV XoRAdx8vBERuYKjbFco+ADMvbu6LjIprkRLEC3UAHWcihMP96mqgimLywAen5AMor60= X-Gm-Gg: AZuq6aKqm3EBLxyL0sr2z2yOPizTaDxme1CMncTQuktk//9Q1Bg++RHKfcErW/HdrYQ O5hESABeg3DCu+qe6XIHJTywtCZI6zbHyusQd4bHgsB3c00FiX1HJPQCn9GIobUIhvRVlHjNlQ3 KP2Z4bYCaact8dFDaMVRugK4SrrxBkI9QrQOmpz0Uwe2VB3Bg8wMzZCIyJuY/bXkZBAlTeyZiZq e+gG7cpPL7RqZqbdMaRfYrCC1lZhWe5f39YT/CVAuWYlnfUIyLkxtyx9JvGhgEspSvuHucgExrz 5Qzp47cZktXlZqGUNHojU8DL9aaRbbjxSPgCIeIVA7TvFWnYOPjbb/4HX+XovOFauYD3+G1iQf6 spg5ONye7AgN3X/9dXj6AM6jAL/hrh3JprCkXf1K2m/1r4NU4ziAP6gW2AUJvKjsRTwRicNkSAN KCPjeFhpjqqSMxdURP0Q== X-Received: by 2002:a7b:c3ce:0:b0:47d:7004:f488 with SMTP id 5b1f17b1804b1-480829b5d53mr130731645e9.10.1770045284797; Mon, 02 Feb 2026 07:14:44 -0800 (PST) Received: from pathway (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-482dbd0f043sm110870995e9.7.2026.02.02.07.14.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 07:14:44 -0800 (PST) Date: Mon, 2 Feb 2026 16:14:42 +0100 From: Petr Mladek To: Aaron Tomlin Cc: akpm@linux-foundation.org, lance.yang@linux.dev, mhiramat@kernel.org, gregkh@linuxfoundation.org, 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: References: <20260128204516.3473709-1-atomlin@atomlin.com> <20260128204516.3473709-2-atomlin@atomlin.com> 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-Disposition: inline In-Reply-To: <20260128204516.3473709-2-atomlin@atomlin.com> On Wed 2026-01-28 15:45:16, 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. This part is true. > 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. > --- 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", s/blocked %s for/blocked%s for/ > + t->comm, t->pid, t->in_iowait ? "in I/O wait" : "", and here: " in I/O wait". Otherwise, it would print two spaces in the non-io case, like" "INFO: task bash:123 blocked for more than 120 seconds" > + (jiffies - t->last_switch_time) / HZ); > pr_err(" %s %s %.*s\n", > print_tainted(), init_utsname()->release, > (int)strcspn(init_utsname()->version, " "), Otherwise, it looks good. Best Regards, Petr