From nobody Thu Jun 25 10:44:09 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47E72C433F5 for ; Mon, 21 Feb 2022 18:30:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231199AbiBUSar (ORCPT ); Mon, 21 Feb 2022 13:30:47 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:48010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230025AbiBUS0s (ORCPT ); Mon, 21 Feb 2022 13:26:48 -0500 X-Greylist: delayed 273 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 21 Feb 2022 10:26:25 PST Received: from mail1.wrs.com (unknown-3-146.windriver.com [147.11.3.146]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2242CC5 for ; Mon, 21 Feb 2022 10:26:25 -0800 (PST) Received: from mail.windriver.com (mail.wrs.com [147.11.1.11]) by mail1.wrs.com (8.15.2/8.15.2) with ESMTPS id 21LIKaY7027189 (version=TLSv1.1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Feb 2022 10:20:37 -0800 Received: from ala-exchng01.corp.ad.wrs.com (ala-exchng01.corp.ad.wrs.com [147.11.82.252]) by mail.windriver.com (8.15.2/8.15.2) with ESMTPS id 21LIKYlq026458 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 21 Feb 2022 10:20:34 -0800 (PST) Received: from ala-exchng01.corp.ad.wrs.com (147.11.82.252) by ala-exchng01.corp.ad.wrs.com (147.11.82.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 21 Feb 2022 10:20:34 -0800 Received: from yow-pgortmak-d4.wrs.com (128.224.56.60) by ala-exchng01.corp.ad.wrs.com (147.11.82.252) with Microsoft SMTP Server id 15.1.2242.12 via Frontend Transport; Mon, 21 Feb 2022 10:20:33 -0800 From: Paul Gortmaker To: , Frederic Weisbecker , Peter Zijlstra CC: Paul Gortmaker , Thomas Gleixner , "Paul E . McKenney" , Ingo Molnar Subject: [PATCH 1/2] sched/isolation: really align nohz_full with rcu_nocbs Date: Mon, 21 Feb 2022 13:20:08 -0500 Message-ID: <20220221182009.1283-2-paul.gortmaker@windriver.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220221182009.1283-1-paul.gortmaker@windriver.com> References: <20220221182009.1283-1-paul.gortmaker@windriver.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" At the moment it is currently possible to sneak a core into nohz_full that lies between nr_possible and NR_CPUS - but you won't "see" it because cpumask_pr_args() implicitly hides anything above nr_cpu_ids. This becomes a problem when the nohz_full CPU set doesn't contain at least one other valid nohz CPU - in which case we end up with the tick_nohz_full_running set and no tick core specified, which trips an endless sequence of WARN() and renders the machine unusable. I inadvertently opened the door for this when fixing an overly restrictive nohz_full conditional in the below Fixes: commit - and then courtesy of my optimistic ACPI reporting nr_possible of 64 (the default Kconfig for NR_CPUS) and the not-so helpful implict filtering done by cpumask_pr_args, I unfortunately did not spot it during my testing. So here, I don't rely on what was printed anymore, but code exactly what our restrictions should be in order to be aligned with rcu_nocbs - which was the original goal. Since the checks lie in "__init" code it is largely free for us to do this anyway. Building with NOHZ_FULL and NR_CPUS=3D128 on an otherwise defconfig, and booting with "rcu_nocbs=3D8-127 nohz_full=3D96-127" on the same 16 core T55= 00 Dell machine now results in the following (only relevant lines shown): smpboot: Allowing 64 CPUs, 48 hotplug CPUs setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:64 nr_node_ids:2 housekeeping: kernel parameter 'nohz_full=3D' or 'isolcpus=3D' contains no= nexistent CPUs. housekeeping: kernel parameter 'nohz_full=3D' or 'isolcpus=3D' has no vali= d CPUs. rcu: RCU restricting CPUs from NR_CPUS=3D128 to nr_cpu_ids=3D64. rcu: Note: kernel parameter 'rcu_nocbs=3D', 'nohz_full', or 'isolcpus= =3D' contains nonexistent CPUs. rcu: Offload RCU callbacks from CPUs: 8-63. One can see both new housekeeping checks are triggered in the above. The same invalid boot arg combination would have previously resulted in an infinitely scrolling mix of WARN from all cores per tick on this box. We may need to revisit these sanity checks when nohz_full is accepted as a stand alone keyword "enable" w/o a cpuset (see rcu/nohz d2cf0854d728). Fixes: 915a2bc3c6b7 ("sched/isolation: Reconcile rcu_nocbs=3D and nohz_full= =3D") Cc: Frederic Weisbecker Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Paul E. McKenney Cc: Ingo Molnar Signed-off-by: Paul Gortmaker --- kernel/sched/isolation.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c index b4d10815c45a..f7d2406c1f1d 100644 --- a/kernel/sched/isolation.c +++ b/kernel/sched/isolation.c @@ -126,6 +126,17 @@ static int __init housekeeping_setup(char *str, unsign= ed long flags) goto free_non_housekeeping_mask; } =20 + if (!cpumask_subset(non_housekeeping_mask, cpu_possible_mask)) { + pr_info("housekeeping: kernel parameter 'nohz_full=3D' or 'isolcpus=3D' = contains nonexistent CPUs.\n"); + cpumask_and(non_housekeeping_mask, cpu_possible_mask, + non_housekeeping_mask); + } + + if (cpumask_empty(non_housekeeping_mask)) { + pr_info("housekeeping: kernel parameter 'nohz_full=3D' or 'isolcpus=3D' = has no valid CPUs.\n"); + goto free_non_housekeeping_mask; + } + alloc_bootmem_cpumask_var(&housekeeping_staging); cpumask_andnot(housekeeping_staging, cpu_possible_mask, non_housekeeping_mask); --=20 2.17.1 From nobody Thu Jun 25 10:44:09 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C61F6C433EF for ; Mon, 21 Feb 2022 18:51:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232540AbiBUSwF (ORCPT ); Mon, 21 Feb 2022 13:52:05 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:34748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232448AbiBUSvj (ORCPT ); Mon, 21 Feb 2022 13:51:39 -0500 Received: from mail1.wrs.com (unknown-3-146.windriver.com [147.11.3.146]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB72EDBA for ; Mon, 21 Feb 2022 10:51:13 -0800 (PST) Received: from mail.windriver.com (mail.wrs.com [147.11.1.11]) by mail1.wrs.com (8.15.2/8.15.2) with ESMTPS id 21LIKavP027190 (version=TLSv1.1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Feb 2022 10:20:37 -0800 Received: from ala-exchng01.corp.ad.wrs.com (ala-exchng01.corp.ad.wrs.com [147.11.82.252]) by mail.windriver.com (8.15.2/8.15.2) with ESMTPS id 21LIKYlr026458 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 21 Feb 2022 10:20:36 -0800 (PST) Received: from ala-exchng01.corp.ad.wrs.com (147.11.82.252) by ala-exchng01.corp.ad.wrs.com (147.11.82.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 21 Feb 2022 10:20:35 -0800 Received: from yow-pgortmak-d4.wrs.com (128.224.56.60) by ala-exchng01.corp.ad.wrs.com (147.11.82.252) with Microsoft SMTP Server id 15.1.2242.12 via Frontend Transport; Mon, 21 Feb 2022 10:20:34 -0800 From: Paul Gortmaker To: , Frederic Weisbecker , Peter Zijlstra CC: Paul Gortmaker , Nicholas Piggin , Thomas Gleixner , Ingo Molnar Subject: [PATCH 2/2] tick/nohz: WARN_ON --> WARN_ON_ONCE to prevent console saturation Date: Mon, 21 Feb 2022 13:20:09 -0500 Message-ID: <20220221182009.1283-3-paul.gortmaker@windriver.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220221182009.1283-1-paul.gortmaker@windriver.com> References: <20220221182009.1283-1-paul.gortmaker@windriver.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" While running some testing on code that happened to allow the variable tick_nohz_full_running to get set but with no "possible" NOHZ cores to back up that setting, I tripped this WARN: if (unlikely(tick_do_timer_cpu =3D=3D TICK_DO_TIMER_NONE)) WARN_ON(tick_nohz_full_running); The console was overwhemled with an endless stream of one WARN per tick per core and there was no way to even see what was going on w/o using a serial console to capture it and then trace it back to this guy. Changing it to ONCE reveals that we get the message we need in a civilized fashion, and the system can limp along until rebooted. Fixes: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full") Cc: Nicholas Piggin Cc: Frederic Weisbecker Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Signed-off-by: Paul Gortmaker --- kernel/time/tick-sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 17a283ce2b20..5e80ee44c32a 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -186,7 +186,7 @@ static void tick_sched_do_timer(struct tick_sched *ts, = ktime_t now) */ if (unlikely(tick_do_timer_cpu =3D=3D TICK_DO_TIMER_NONE)) { #ifdef CONFIG_NO_HZ_FULL - WARN_ON(tick_nohz_full_running); + WARN_ON_ONCE(tick_nohz_full_running); #endif tick_do_timer_cpu =3D cpu; } --=20 2.17.1