From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-155.mta1.migadu.com [95.215.58.155]) (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 1B0D53E5592 for ; Fri, 14 Aug 2026 15:58:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.155 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786723125; cv=none; b=rvthzyMcVHlx6gsctCKOaXx/6Yt88cAt5qn/Qibb+BEQ+6/+br2ZaDGrEiAptWJKXdfL/NjdxAQnwLxfbGxPJb4mVSSy3N0bx3cFArO00BFTdnelD3vh5XF+5rOgHmPNQP+kq7dQ8i4MmrzYxGB0mwZV7v4F/hfNmRsgLEHjeOE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786723125; c=relaxed/simple; bh=siPrrmuA3CymWFhwf4B5IPtrQo1aTV4OyrJYa73r7BU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=bq1KzUyVbTyw5PHiRS2jZsngmwCY56ez0ty75MRVabgE0xlcMZQjEaIWaVNsQi5WarV4TGewrdjBvztC0t/xu2BrIlI2tcgq3TXUxNCTPDlPgfu1T0UsAA/n+BM6vo7mqim0iHoATxZ/R0+am7JmEg9kLXtWQC15nyu3VqJk/U4= 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=YQPHUL0u; arc=none smtp.client-ip=95.215.58.155 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="YQPHUL0u" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=siPrrmuA3CymWFhwf4B5IPtrQo1aTV4OyrJYa73r7BU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786723120; v=1; x=1787327920; b=YQPHUL0u5A2ng4CVtpReT9qA8fM6J0MEYUvZtyj3P0MPNYl/t9AF2jSH+xn3L99cZBWzkymO O2nQDIL6Y7NG2XpBtntLvTpognqBRiPrbMLv0XJwFGp9hZZGv9Qh1tiGNIwmCP5DKvjRg3JeYUx XT7XLQ0VNS9Nyoeo0zLPFJN4= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (183.241.20.126) by smtp.migadu.com with ESMTPS id 554933b681997f81; Fri, 14 Aug 2026 15:58:30 +0000 X-Migadu-Flow: FLOW_OUT From: Lance Yang To: atomlin@atomlin.com Cc: akpm@linux-foundation.org, mhiramat@kernel.org, pmladek@suse.com, linux-kernel@vger.kernel.org, david.laight.linux@gmail.com, neelx@suse.com, sean@ashe.io, chjohnst@gmail.com, steve@abita.co, mproche@gmail.com, nick.lange@gmail.com, Lance Yang Subject: Re: [PATCH v9 1/2] hung_task: Reset warning budget when problem gets resolved Date: Fri, 14 Aug 2026 23:58:21 +0800 Message-Id: <20260814155821.75422-1-lance.yang@linux.dev> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260814135718.494513-2-atomlin@atomlin.com> References: <20260814135718.494513-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=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Aug 14, 2026 at 09:57:17AM -0400, Aaron Tomlin wrote: >The sysctl hung_task_warnings currently holds both the configured warning >limit and the remaining budget. Each detailed report decrements the >sysctl, so once it reaches zero, the configured limit is lost and cannot >be restored automatically. > >Keep sysctl hung_task_warnings unchanged and track the remaining budget >in hung_task_warnings_printed. Reset the runtime budget via an atomic flag >when a watchdog check sees no hung tasks or when userspace writes a new >sysctl value. Only sysctl writes go through reset_hung_task_warnings; no-hung case reloads budget directly. Also worth spelling out why flag is there: keeping runtime budget khungtaskd-owned. I'd write it as: Keep sysctl_hung_task_warnings as the configured warning limit and make khungtaskd the sole owner of the remaining budget. A check that finds no hung tasks reloads the budget directly from the configured limit. A successful sysctl write publishes an atomic reset request, which khungtaskd consumes at the start of the next check. No need to resend just for this, though. I think Andrew can fix that up when applying. >Suggested-by: Petr Mladek >Suggested-by: Lance Yang >Tested-by: Lance Yang >Signed-off-by: Aaron Tomlin >--- Nothing jumped out at me, thanks! Reviewed-by: Lance Yang