From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.zx2c4.com (lists.zx2c4.com [165.227.139.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 82C27CF34D9 for ; Wed, 19 Nov 2025 15:48:26 +0000 (UTC) Received: by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTP id df487443; Tue, 18 Nov 2025 17:32:38 +0000 (UTC) Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [2001:41d0:1004:224b::b3]) by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id 3960f688 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Thu, 16 Oct 2025 05:07:44 +0000 (UTC) Message-ID: <4db3bd26-1f74-4096-84fd-f652ec9a4d27@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1760591263; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SCAq3Tpy90yiw+VRqp/jzmhdqwWtKZRonlnTXaNao8c=; b=geBJxByLcvWBiujKOiaOahCqNyndVoWuu2mZ45TF8xE284+jE46+6ntqZCrEJOY3tjLJtS CA04TcSdtSgMTu+1LyL0JCiZYt8KyHlnhHzez+oDkOoqTGathzLcXzzn8tcestdiOMA31r Wv+r/T6z/ByuejbAoTutxC4uLBsXkfs= Date: Thu, 16 Oct 2025 13:07:23 +0800 MIME-Version: 1.0 Subject: Re: [PATCH][v4] hung_task: Panic when there are more than N hung tasks at the same time Content-Language: en-US To: lirongqing , Andrew Morton Cc: linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, wireguard@lists.zx2c4.com, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, Masami Hiramatsu , Andrew Jeffery , Anshuman Khandual , Arnd Bergmann , David Hildenbrand , Florian Wesphal , Jakub Kacinski , "Jason A . Donenfeld" , Joel Granados , Joel Stanley , Jonathan Corbet , Kees Cook , Liam Howlett , Lorenzo Stoakes , "Paul E . McKenney" , Pawan Gupta , Petr Mladek , Phil Auld , Randy Dunlap , Russell King , Shuah Khan , Simon Horman , Stanislav Fomichev , Steven Rostedt , linux-kernel@vger.kernel.org References: <20251015063615.2632-1-lirongqing@baidu.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <20251015063615.2632-1-lirongqing@baidu.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Mailman-Approved-At: Tue, 18 Nov 2025 17:23:16 +0000 X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" LGTM. It works as expected, thanks! On 2025/10/15 14:36, lirongqing wrote: > From: Li RongQing For the commit message, I'd suggest the following for better clarity: ``` The hung_task_panic sysctl is currently a blunt instrument: it's all or nothing. Panicking on a single hung task can be an overreaction to a transient glitch. A more reliable indicator of a systemic problem is when multiple tasks hang simultaneously. Extend hung_task_panic to accept an integer threshold, allowing the kernel to panic only when N hung tasks are detected in a single scan. This provides finer control to distinguish between isolated incidents and system-wide failures. The accepted values are: - 0: Don't panic (unchanged) - 1: Panic on the first hung task (unchanged) - N > 1: Panic after N hung tasks are detected in a single scan The original behavior is preserved for values 0 and 1, maintaining full backward compatibility. ``` If you agree, likely no need to resend - Andrew could pick it up directly when applying :) > > Currently, when 'hung_task_panic' is enabled, the kernel panics > immediately upon detecting the first hung task. However, some hung > tasks are transient and allow system recovery, while persistent hangs > should trigger a panic when accumulating beyond a threshold. > > Extend the 'hung_task_panic' sysctl to accept a threshold value > specifying the number of hung tasks that must be detected before > triggering a kernel panic. This provides finer control for environments > where transient hangs may occur but persistent hangs should be fatal. > > The sysctl now accepts: > - 0: don't panic (maintains original behavior) > - 1: panic on first hung task (maintains original behavior) > - N > 1: panic after N hung tasks are detected in a single scan > > This maintains backward compatibility while providing flexibility for > different hang scenarios. > > Signed-off-by: Li RongQing > Cc: Andrew Jeffery > Cc: Anshuman Khandual > Cc: Arnd Bergmann > Cc: David Hildenbrand > Cc: Florian Wesphal > Cc: Jakub Kacinski > Cc: Jason A. Donenfeld > Cc: Joel Granados > Cc: Joel Stanley > Cc: Jonathan Corbet > Cc: Kees Cook > Cc: Lance Yang > Cc: Liam Howlett > Cc: Lorenzo Stoakes > Cc: "Masami Hiramatsu (Google)" > Cc: "Paul E . McKenney" > Cc: Pawan Gupta > Cc: Petr Mladek > Cc: Phil Auld > Cc: Randy Dunlap > Cc: Russell King > Cc: Shuah Khan > Cc: Simon Horman > Cc: Stanislav Fomichev > Cc: Steven Rostedt > --- So: Reviewed-by: Lance Yang Tested-by: Lance Yang Cheers, Lance