From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 7D3A6336EDA for ; Tue, 10 Feb 2026 09:40:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770716446; cv=none; b=MgjAvFoBmfTLc3Aj5H1PZ7L8tlkyqVj4X4/StE58lXeO8gPq9cO4angehIu107DsHZezpxuptsh6oDW0S6HwBLudYWAezLQS10gnCpQhsPLPw32bhKFIGQV2ctJ2rHci57HK1cWBe5LbPaRDItRyfMSb3i7oQKjWKVSoUyCcEDc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770716446; c=relaxed/simple; bh=zYwvg1iVjBDBXK+VJn4+R2O4LqR88VsM0zCtKJrqnV0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PLQDaADsxm3fXciS+ybjE8xTg6qWfWOXkJuo8KbmuFy7doEX65Dkk0UfmmahYKDFvgfFmFbMASYVGIB9i0A7JZDrPFRva8z7k/rv/bJQ64E6CeMLCj+kf1i4L4gH8kn5RFCkTnReBOz72yGDYNmr8BmBrwCFIGxCiP0580aPNcA= 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=fpx4TxPj; arc=none smtp.client-ip=209.85.128.41 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="fpx4TxPj" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4834826e5a0so6993445e9.2 for ; Tue, 10 Feb 2026 01:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1770716443; x=1771321243; 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=yvLlNWYbN/h9UFuOwZt0Jjb2TUZTOT7L8paKKiOBvi8=; b=fpx4TxPjo9bAqAxgC601JJy5B48SFhkQN16tM5lWwCA1bxXoIQtG4vt7qZXPdYT+nJ pjIXkoxhN9eQXjD4XRm+s9DhJnhks1f7OWJqWoJRL3nZBDQ92sqI1G+vZRgjrt82I8gH 0dRhrTS5ATpW/BDOUrV2aijYjVCOUrgl2RRn1EkOwhB7fnss8i5nqRVECN2E7ca3DZ3n z5evtELKKlRvECPOmp6h1PK024ugF0NbVlq8pI6wdbvkck6vdQl7Kzq0iPgFlZ2OD1q8 B0yGzPUk6CYJKnCbozF69Hb2FpDpoctaFh503VPeD7Nddpa3IbYXsyWjaqh1/9YX0Zdc IHQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770716443; x=1771321243; 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=yvLlNWYbN/h9UFuOwZt0Jjb2TUZTOT7L8paKKiOBvi8=; b=NftGzmnfBolSuRB5wG4w8vif1vsXfRTIMOMarOQoh0I8OrAQnl8hl0hpFMg5Z818LR uBbSRIKY2WGgkZ6ajPfm4IBq1FujBjl2ioTmaVYK6HkPqBCywFeFec0ZMNI+5NEpLkrT sZEmjT0mW3QI8lLOTU5xxLkAdE6JD79n4o360qE1DeDUx3P1BfKdfykcJmVpw7AJ8Xxn 2FGDeW0x/lfHuNOwkPNuax4NmwWRY+BlrhuJof8ZLfbJbyRqXwuMBtMiJXPcBw90XeWY UJx4trX62qdkpcO4S0FSQEU2Vw23dF2YBGB311fSbd9/qHEXqJGdpL0sS3qIUvAlo1wo Wj1Q== X-Forwarded-Encrypted: i=1; AJvYcCXnh+4nJRN1vnSyfC03P5gJMRfXjo6aKFrk3Yh+TU2yiqCSJg+8V8g0IV955umgxNM6X/ebhi6qJCt3o+I=@vger.kernel.org X-Gm-Message-State: AOJu0YwIlEftXJS32910tQP+K6c/xrWvi0HjyKiPujo5Q2NavMsQRtxX xKMcvcZhDdIyGDawwCcNqyXk/47GMEcKcR0eZzRfAbU8KsaNNYMLbCJaX/R1/Q0b/Ec= X-Gm-Gg: AZuq6aK6oZBPSETWOi6aX00nBRZ5+c7kB2RuqDxSbHbR3UJYBQsqS84iSzZk6kGP8AF iV0aczlX+gB8bNDGX0SRhHyNhw3YCK0IxOFXsnAKoadrdYSAz3HrSGVW3CxkdNq9U9So4f8R3HR CfTkI3HmUbWhh4mRhDFVPiGnszOI9LWuCdDWe2Uq2DO0/xZxBFQ2mBTmQ7ZWl2nZHmqH5x7mvFs aMc8NOmortvlG2WSxCYceVNXyj21gVMNrpOdNdo41D2vdYiUZe7kT0uJClBgzPXocqXZwk24p7z eYaEqrgXHpjgea52egqZcZFb3zgR3P0kryhYQYQoEsOLx4WYwBMkPcqYqBtwt2odB3Qu4ZIl9mF bq9/HsnoBfDRvLHa3b6s3qIdfpvp/+dkvf+FWcpKiwA+Rco/9ZK4fE9/zvDW788Qru2E7ZmBIQJ CXtOSGaO+GptbXVD7nWSfmyb9mVdxWec3rivSnQComXFI2punaSEE= X-Received: by 2002:a05:600c:3f08:b0:465:a51d:d4 with SMTP id 5b1f17b1804b1-483201dd06bmr212449205e9.6.1770716442782; Tue, 10 Feb 2026 01:40:42 -0800 (PST) Received: from pathway.suse.cz (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4832041f1a3sm140326845e9.7.2026.02.10.01.40.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 01:40:42 -0800 (PST) Date: Tue, 10 Feb 2026 10:40:40 +0100 From: Petr Mladek To: Aaron Tomlin Cc: akpm@linux-foundation.org, lance.yang@linux.dev, mhiramat@kernel.org, gregkh@linuxfoundation.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 v3] hung_task: Explicitly report I/O wait state in log output Message-ID: References: <20260208002458.3791059-1-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: On Mon 2026-02-09 09:30:34, Aaron Tomlin wrote: > On Mon, Feb 09, 2026 at 11:14:27AM +0100, Petr Mladek wrote: > > > 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 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. > > > > IMHO, this is not true. The blocked tasks might wake up at any time. > > There is a small chance to print an inconsistent information. > > But we could live with it. The entire hung task report is racy. > > > > The race would actually be a lucky moment where the task get > > unblocked. In this case, it won't be reported in the next > > round... > > > > I suggest to omit the entire paragraph. > > > > > Acked-by: Masami Hiramatsu (Google) > > > Signed-off-by: Aaron Tomlin > > > > Othrewise, it looks good. > > > > With the removed paragraph: > > > > Reviewed-by: Petr Mladek > > Hi Petr, Lance, > > Apologies. The old commit message was erroneously used. > > I would prefer to replace the last paragraph with the following to reflect > that this is a diagnostic snapshot only: > > Theoretically, io_schedule_finish() could be called immediately after > khungtaskd checks the flag, rendering the output stale. However, > strictly preventing this would require blocking the waking task (e.g., > within the mutex unlock code path - see mutex_lock_io()) to inhibit the > state change during the scan. This seems entirely disproportionate for > a "best effort" diagnostic tool, especially given the probability of > such a race is negligible after a long hang, by default. > > Please let me know your thoughts. Strictly speaking, io_schedule_finish() might be called even before khungtaskd checks the flag. It can be called in parallel at any time. The entire khungtaskd out is racy. But it is good enough in practice, especially because it reports stalls. The chance that a long stall gets finished while the report is being printed is very small. And you are right. Any attempt to serialize the output seems disproportionate here. It might make the stall even worse. If you really want to write something about the possible race then I would write something like: Theoretically, io_schedule_finish() could be called in parallel and the read flag need not match the later printed backtrace. It should be acceptable in practice. The entire report is racy. And it works most of the time, especially because long stalls are being reported. And adding any extra synchronization seems entirely disproportionate in this scenario. Best Regards, Petr