From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx3.molgen.mpg.de (mx3.molgen.mpg.de [141.14.17.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87975262FE9; Thu, 16 Oct 2025 12:51:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=141.14.17.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760619085; cv=none; b=cQH5d2v4iWbi76b0xYj8mmogfu6iBIcgWWEvUQD61aOjtHC+NLpOFjtnQ5N/G1nHBjsW3+0Uq2YcVKGVWvEBF5HcPBFS/CltbmWpkybBi7EDJpy5dXxhhhv6B3FEdKZPhgBYiwOkxZUPAwLrkSUxb0t3wepVoo9nVbXJ+b15wUQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760619085; c=relaxed/simple; bh=sgjsbnfjXYxa02QLAzec2StJYwfXNJTdwY/bMDFhByI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dmoO8BFplnQFjCcaGeHeBi9wkYRfjypycR+9cTCQpaU1uWknIqIq/YqXtaEw8cecV36kqNwQz2GR3RgDcCWdXzZNQpz+75xWelMZCJ2Q5C8N1nCfxbabF0hgDRVLJoQaGs8/BO+ts+ICa2mFZHdQI0y3Z7wT2dXPWcCtiTMSKBw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=molgen.mpg.de; spf=pass smtp.mailfrom=molgen.mpg.de; arc=none smtp.client-ip=141.14.17.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=molgen.mpg.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=molgen.mpg.de Received: from [141.14.220.42] (g42.guest.molgen.mpg.de [141.14.220.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id CC355601B357B; Thu, 16 Oct 2025 14:47:52 +0200 (CEST) Message-ID: <906dd11d-26db-4570-840a-e4797748c05c@molgen.mpg.de> Date: Thu, 16 Oct 2025 14:47:51 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH][v4] hung_task: Panic when there are more than N hung tasks at the same time To: Li RongQing Cc: Andrew Morton , Lance Yang , Masami Hiramatsu , linux-kernel@vger.kernel.org, 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, 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 References: <20251015063615.2632-1-lirongqing@baidu.com> Content-Language: en-US From: Paul Menzel In-Reply-To: <20251015063615.2632-1-lirongqing@baidu.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear RongQing, Thank you for the patch. One minor comment regarding the Kconfig description. Am 15.10.25 um 08:36 schrieb lirongqing: > From: Li RongQing > > 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 > --- > diff with v3: comments modification, suggested by Lance, Masami, Randy and Petr > diff with v2: do not add a new sysctl, extend hung_task_panic, suggested by Kees Cook > > Documentation/admin-guide/kernel-parameters.txt | 20 +++++++++++++------- > Documentation/admin-guide/sysctl/kernel.rst | 9 +++++---- > arch/arm/configs/aspeed_g5_defconfig | 2 +- > kernel/configs/debug.config | 2 +- > kernel/hung_task.c | 15 ++++++++++----- > lib/Kconfig.debug | 9 +++++---- > tools/testing/selftests/wireguard/qemu/kernel.config | 2 +- > 7 files changed, 36 insertions(+), 23 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index a51ab46..492f0bc 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1992,14 +1992,20 @@ > the added memory block itself do not be affected. > > hung_task_panic= > - [KNL] Should the hung task detector generate panics. > - Format: 0 | 1 > + [KNL] Number of hung tasks to trigger kernel panic. > + Format: > + > + When set to a non-zero value, a kernel panic will be triggered if > + the number of detected hung tasks reaches this value. > + > + 0: don't panic > + 1: panic immediately on first hung task > + N: panic after N hung tasks are detected in a single scan > > - A value of 1 instructs the kernel to panic when a > - hung task is detected. The default value is controlled > - by the CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time > - option. The value selected by this boot parameter can > - be changed later by the kernel.hung_task_panic sysctl. > + The default value is controlled by the > + CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time option. The value > + selected by this boot parameter can be changed later by the > + kernel.hung_task_panic sysctl. > > hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC) > terminal devices. Valid values: 0..8 > diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst > index f3ee807..0065a55 100644 > --- a/Documentation/admin-guide/sysctl/kernel.rst > +++ b/Documentation/admin-guide/sysctl/kernel.rst > @@ -397,13 +397,14 @@ a hung task is detected. > hung_task_panic > =============== > > -Controls the kernel's behavior when a hung task is detected. > +When set to a non-zero value, a kernel panic will be triggered if the > +number of hung tasks found during a single scan reaches this value. > This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. > > -= ================================================= > += ======================================================= > 0 Continue operation. This is the default behavior. > -1 Panic immediately. > -= ================================================= > +N Panic when N hung tasks are found during a single scan. > += ======================================================= > > > hung_task_check_count […] > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 3034e294..3976c90 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1258,12 +1258,13 @@ config DEFAULT_HUNG_TASK_TIMEOUT > Keeping the default should be fine in most cases. > > config BOOTPARAM_HUNG_TASK_PANIC > - bool "Panic (Reboot) On Hung Tasks" > + int "Number of hung tasks to trigger kernel panic" > depends on DETECT_HUNG_TASK > + default 0 > help > - Say Y here to enable the kernel to panic on "hung tasks", > - which are bugs that cause the kernel to leave a task stuck > - in uninterruptible "D" state. > + When set to a non-zero value, a kernel panic will be triggered > + if the number of hung tasks found during a single scan reaches > + this value. > > The panic can be used in combination with panic_timeout, > to cause the system to reboot automatically after a Why not leave the sentence about the uninterruptible "D" state in there? Also, it sounds like, some are actually using this in production. Maybe it should be moved out of `Kconfig.debug` too? Kind regards, Paul