From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1D492268FF0; Tue, 8 Apr 2025 10:55:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744109728; cv=none; b=jpnOS2xyHwywjqMsh/MF4MW+191jqsRIS5gv8Mn5lT8DPtvo4uoRUQnfS+SAoi6BkOjm0f5idlfLgeDcNtW6MoI5vfeRuZfq/s8OIYJj5mGjzuGKgphfiKlzPrBZD28rFinCuZEfRfwkqM6+QMKFjpt6MRjWVHTaxSy1oVTKjWg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744109728; c=relaxed/simple; bh=qTDlU+uUYsIQtWJ+WqUkZxLJJ4fezjv2DmSkX8yEugA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UTX9VlkgTL+Jx+DAnlk4mziAlE4eyma93qY7VqIghScmX4ecXzE03s/QRmIOOEp1yH/CCuLhaSC/x+M+GzRGtHYxCoJkRaGVh2nZXhOzZqZ2TLHa/rm7pzc8t+gvehW+u9vrWMDGUTbg6y4JPHVSveK9OcOLlZKEtC7vLDSZ6zU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=cAJBWeWQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="cAJBWeWQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C80CC4CEE7; Tue, 8 Apr 2025 10:55:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1744109727; bh=qTDlU+uUYsIQtWJ+WqUkZxLJJ4fezjv2DmSkX8yEugA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cAJBWeWQg6jaK9Qc7zY+wG9LNk/cSnaKE78usPcxxI6w36aHfXRpOfX/YhJ52viWV ctmMyKqYf1P3wkGYKvKRcKN2uaEod5P4W95L8nCWS16ZvRyE560mtshkbEfRFmjW4S ylXXX48sLW3YdVu8N26k7JrPHWmM6MBcVUqKYGl8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Chris von Recklinghausen , Oleg Nesterov , Thomas Gleixner , Ingo Molnar , Phil Auld , Frederic Weisbecker , Krishanth Jagaduri Subject: [PATCH 5.10 003/227] sched/isolation: Prevent boot crash when the boot CPU is nohz_full Date: Tue, 8 Apr 2025 12:46:21 +0200 Message-ID: <20250408104820.464646247@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250408104820.353768086@linuxfoundation.org> References: <20250408104820.353768086@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Oleg Nesterov Documentation/timers/no_hz.rst states that the "nohz_full=" mask must not include the boot CPU, which is no longer true after: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full"). However after: aae17ebb53cd ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") the kernel will crash at boot time in this case; housekeeping_any_cpu() returns an invalid CPU number until smp_init() brings the first housekeeping CPU up. Change housekeeping_any_cpu() to check the result of cpumask_any_and() and return smp_processor_id() in this case. This is just the simple and backportable workaround which fixes the symptom, but smp_processor_id() at boot time should be safe at least for type == HK_TYPE_TIMER, this more or less matches the tick_do_timer_boot_cpu logic. There is no worry about cpu_down(); tick_nohz_cpu_down() will not allow to offline tick_do_timer_cpu (the 1st online housekeeping CPU). [ Apply only documentation changes as commit which causes boot crash when boot CPU is nohz_full is not backported to stable kernels - Krishanth ] Reported-by: Chris von Recklinghausen Signed-off-by: Oleg Nesterov Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Reviewed-by: Phil Auld Acked-by: Frederic Weisbecker Link: https://lore.kernel.org/r/20240411143905.GA19288@redhat.com Closes: https://lore.kernel.org/all/20240402105847.GA24832@redhat.com/ Signed-off-by: Krishanth Jagaduri [ strip out upstream commit and Fixes: so tools don't get confused that this commit actually does anything real - gregkh] Signed-off-by: Greg Kroah-Hartman --- Documentation/timers/no_hz.rst | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) --- a/Documentation/timers/no_hz.rst +++ b/Documentation/timers/no_hz.rst @@ -129,11 +129,8 @@ adaptive-tick CPUs: At least one non-ad online to handle timekeeping tasks in order to ensure that system calls like gettimeofday() returns accurate values on adaptive-tick CPUs. (This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no running -user processes to observe slight drifts in clock rate.) Therefore, the -boot CPU is prohibited from entering adaptive-ticks mode. Specifying a -"nohz_full=" mask that includes the boot CPU will result in a boot-time -error message, and the boot CPU will be removed from the mask. Note that -this means that your system must have at least two CPUs in order for +user processes to observe slight drifts in clock rate.) Note that this +means that your system must have at least two CPUs in order for CONFIG_NO_HZ_FULL=y to do anything for you. Finally, adaptive-ticks CPUs must have their RCU callbacks offloaded.