From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 A0B0335F8CF for ; Mon, 2 Feb 2026 12:59:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770037165; cv=none; b=lMDJmh4W2eEpjIk7QbRVLX7eyS2SJt5u8ViKyWmnuNQzCeS6oNitkjsa45W1bynwXQX5fx7zr3exobdP8bRGbpuH7nyWc6dph82anzcBeKUXJI8cxU3wLVeN9UWdh35CvdFKBfvI6pVC9jAbYwAnNzD/dHjKW0EN88d7uArBxGo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770037165; c=relaxed/simple; bh=6Ka+If2nvNjbGy9anUNvxwoxZbt+S1JklbbF8D+ZABs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GQYVW/yLMR9LiHJx1idmRvNRtFrltigyUAOplW3yUgz+HZbNbANgPPY6pjnHS8bA4wla7uT2uDx1FY9fpfmb6moH6nhQBTQfFgh3NWCs0CyAYQmwRG8kq8QopO+VSDypSinzybEhXu+s1sQexcpH6VRjU0j9cIZg9H0obzCDYgY= 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=OXYOKX2w; arc=none smtp.client-ip=209.85.221.50 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="OXYOKX2w" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-42fb6ce71c7so3642754f8f.1 for ; Mon, 02 Feb 2026 04:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1770037162; x=1770641962; 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=pBees0HmZce3IpABCFNseft9rOQwST8/r2xlwggwJnk=; b=OXYOKX2weQyqc6rVNsfmrhtRVaK4tOJv158iCTZTnfSBMHHA++ffWz3PGDnOBGRxAe exq2eUheLmBomAP33buslDKAmaKzwa40wXgtbt6cqgRtxAAExQArXijvRz0HNcRAXTbR 7N06b0Ld3E4eFQL9IcTD9iXEyubnSHEMumXJTqQh4ohnQQkX0lUTBuezsGzN6Wp4uLvy QItJLE/+EvgB1OmvBbW66e4aHkwARD0ZTZk/hWLGmvNKteJp4q9ts2uAZDjEKBsuaKjy CINxIrIXfJ1p3wUNKZJsVNLP044eXui1esFAuht5Cu62L6QAFp+vaAtRUvZzZS7pLDsl 7YQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770037162; x=1770641962; 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=pBees0HmZce3IpABCFNseft9rOQwST8/r2xlwggwJnk=; b=wPyw8CKm2Mkow6Bs1/pitB4SmfAuIkOD/mcpg/ZKUIwryoGI3T7iuj0aN8Mpcu/4wu u/xnfCBhoDtvVyM49hai3a608v0KDVEn7S6o4MtqfYW0Jmy/Z/B1AU0Tr4XJlQ8WmWeG oiIH2A85/+skovmyUZtrAW6v1bUAAWxPN+HbTXzL+pRUkRGvVp4NTPcePb8D0yCt6nu6 TORC+aRXty6VelmbTDMXh+QceTh69k96KXwpvVUNNi9grk6M0FJSW0kaHwsvyKU2KFu9 6iSnJS04ONxFRAvLxTb9/4so8ggHN1bJChGi1HUbivZjf+7/pzaomEfIdGPd/y2W5g06 pHtg== X-Forwarded-Encrypted: i=1; AJvYcCW82vs9ag6EMjK/Ht/sV2xFwIjE5IVTfRRsnCAy/lCEPD3tBS+ybTdutNjXkBYJtPZotKn6LdYNGB0KBuU=@vger.kernel.org X-Gm-Message-State: AOJu0YzPe2AV5W+pAjvEzB78jWZycDolmgYEKqRw1I7qCDFhgMMPqLqW nO5SnMM7CjzFLmdARXEXvwmFl3jPkXmTQ9kIgL1sQhi52CWjQ9Q9sWL6G0hWBEsrrks= X-Gm-Gg: AZuq6aL/93134Z9hVQDBH4L85vC6mgH8QWuyeRwqPdp2tqPzPAGMicZlAZhAEcskIQc U1HiMC3ixNh1K565+YmSDkOyYs6vtjlrcnfvQQGLzNuIpsM9Th6BPz4N704phSjr4h4neRjibI7 mWwaBSeCQPy01ZiJXjOqZgFnwoyZyLBxyvc81UvwijBQmnqTE9fD7cr/JZ+qSHEsh//o/pNHFDl 7ZQLduOQ0wBSJZixfXrkD3cP+fOxSNhp/cKJ1U/oP9A/lCCRhesiVJeXvbOYmN6NFcXO7HqD4V1 6HS5M2ddQZJByBWeaXrBWRJFesSNGSWqaUdGwjOc8RoN874fFBJbGLWf1q1l4F5nBdZaRJYU9qj fvnAVj5Ws1RMcKgvOx+lA3f5EB4i5jO64x/7T5fPmrzOCywXJmKFVJ0ba5XNqsUOJ4DaUId8cJc vIK2uTxhC15AttiKD7cA== X-Received: by 2002:a05:6000:401f:b0:430:f241:a11f with SMTP id ffacd0b85a97d-435f3aaa5aemr15306170f8f.30.1770037162037; Mon, 02 Feb 2026 04:59:22 -0800 (PST) Received: from pathway (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10edfccsm42142439f8f.17.2026.02.02.04.59.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 04:59:21 -0800 (PST) Date: Mon, 2 Feb 2026 13:59:17 +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: [v7 PATCH 1/2] hung_task: Refactor detection logic and atomicise detection count Message-ID: References: <20260125135848.3356585-1-atomlin@atomlin.com> <20260125135848.3356585-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: <20260125135848.3356585-2-atomlin@atomlin.com> On Sun 2026-01-25 08:58:47, Aaron Tomlin wrote: > The check_hung_task() function currently conflates two distinct > responsibilities: validating whether a task is hung and handling the > subsequent reporting (printing warnings, triggering panics, or > tracepoints). > > This patch refactors the logic by introducing hung_task_info(), a > function dedicated solely to reporting. The actual detection check, > task_is_hung(), is hoisted into the primary loop within > check_hung_uninterruptible_tasks(). This separation clearly decouples > the mechanism of detection from the policy of reporting. > > Furthermore, to facilitate future support for concurrent hung task > detection, the global sysctl_hung_task_detect_count variable is > converted from unsigned long to atomic_long_t. Consequently, the > counting logic is updated to accumulate the number of hung tasks locally > (this_round_count) during the iteration. The global counter is then > updated atomically via atomic_long_cmpxchg_relaxed() once the loop > concludes, rather than incrementally during the scan. > > These changes are strictly preparatory and introduce no functional > change to the system's runtime behaviour. > > Signed-off-by: Aaron Tomlin LGTM. Feel free to use: Reviewed-by: Petr Mladek Best Regards, Petr