From nobody Wed Dec 17 09:45:05 2025 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 9CDEBC25B70 for ; Fri, 27 Oct 2023 18:46:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346456AbjJ0Sq4 (ORCPT ); Fri, 27 Oct 2023 14:46:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346405AbjJ0Sqh (ORCPT ); Fri, 27 Oct 2023 14:46:37 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 409AF1AC; Fri, 27 Oct 2023 11:46:34 -0700 (PDT) Date: Fri, 27 Oct 2023 18:46:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1698432391; h=from:from:sender:sender:reply-to: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=f6EBd7CQLyZiNig/spAOzxNR1L2frOSZ4YESWGhvmLI=; b=jCFQYvkce+A6qqFPkuK+ohh8vzqjbpErin0g6q/Pj1+B6epLkqbDewNI2IvrZ3NeLLlUtm nPmPhtw9Ik6ZkuKcAlKIXU4UHs/bPHLC0Q2X9e0UEBSwza7Gls1M42d8wxuErn3N3VRCpl dz8+oczq8j4EXHT0gW91ZprqAgkhbWFvvmXFM/dx2+Lft414plNXMlRPF5ZN+vkp/9IlO5 ozlsHmcDPDDuNwDjshkRuyPxSfev1k895I0z2dT6bYPiqAnXN2b86Jyo/vOPecjmON2cWx CORhlgQQpocALCG5drpoOzOziSa4deKhOld4X4TPNitfUgpuzRp36N/Y8C0qNg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1698432392; h=from:from:sender:sender:reply-to: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=f6EBd7CQLyZiNig/spAOzxNR1L2frOSZ4YESWGhvmLI=; b=KOYeO9YZgSMaiafzoXp+3jHsJHVJU9NxqThmxSTpRRHGANRsaGmpVLVjL/t0UpE4/xw5MX SOtDp637ghfH4WDw== From: "tip-bot2 for Thomas Gleixner" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/urgent] x86/tsc: Defer marking TSC unstable to a worker Cc: Tetsuo Handa , Thomas Gleixner , stable@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <87zg064ceg.ffs@tglx> References: <87zg064ceg.ffs@tglx> MIME-Version: 1.0 Message-ID: <169843239104.3135.3490038788401849491.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/urgent branch of tip: Commit-ID: bd94d86f490b70c58b3fc5739328a53ad4b18d86 Gitweb: https://git.kernel.org/tip/bd94d86f490b70c58b3fc5739328a53ad= 4b18d86 Author: Thomas Gleixner AuthorDate: Wed, 25 Oct 2023 23:31:35 +02:00 Committer: Thomas Gleixner CommitterDate: Fri, 27 Oct 2023 20:36:57 +02:00 x86/tsc: Defer marking TSC unstable to a worker Tetsuo reported the following lockdep splat when the TSC synchronization fails during CPU hotplug: tsc: Marking TSC unstable due to check_tsc_sync_source failed =20 WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. ffffffff8cfa1c78 (watchdog_lock){?.-.}-{2:2}, at: clocksource_watchdog+0= x23/0x5a0 {IN-HARDIRQ-W} state was registered at: _raw_spin_lock_irqsave+0x3f/0x60 clocksource_mark_unstable+0x1b/0x90 mark_tsc_unstable+0x41/0x50 check_tsc_sync_source+0x14f/0x180 sysvec_call_function_single+0x69/0x90 Possible unsafe locking scenario: lock(watchdog_lock); lock(watchdog_lock); stack backtrace: _raw_spin_lock+0x30/0x40 clocksource_watchdog+0x23/0x5a0 run_timer_softirq+0x2a/0x50 sysvec_apic_timer_interrupt+0x6e/0x90 The reason is the recent conversion of the TSC synchronization function during CPU hotplug on the control CPU to a SMP function call. In case that the synchronization with the upcoming CPU fails, the TSC has to be marked unstable via clocksource_mark_unstable(). clocksource_mark_unstable() acquires 'watchdog_lock', but that lock is taken with interrupts enabled in the watchdog timer callback to minimize interrupt disabled time. That's obviously a possible deadlock scenario, Before that change the synchronization function was invoked in thread context so this could not happen. As it is not crucical whether the unstable marking happens slightly delayed, defer the call to a worker thread which avoids the lock context problem. Fixes: 9d349d47f0e3 ("x86/smpboot: Make TSC synchronization function call b= ased") Reported-by: Tetsuo Handa Signed-off-by: Thomas Gleixner Tested-by: Tetsuo Handa Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87zg064ceg.ffs@tglx --- arch/x86/kernel/tsc_sync.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c index bbc440c..1123ef3 100644 --- a/arch/x86/kernel/tsc_sync.c +++ b/arch/x86/kernel/tsc_sync.c @@ -15,6 +15,7 @@ * ( The serial nature of the boot logic and the CPU hotplug lock * protects against more than 2 CPUs entering this code. ) */ +#include #include #include #include @@ -342,6 +343,13 @@ static inline unsigned int loop_timeout(int cpu) return (cpumask_weight(topology_core_cpumask(cpu)) > 1) ? 2 : 20; } =20 +static void tsc_sync_mark_tsc_unstable(struct work_struct *work) +{ + mark_tsc_unstable("check_tsc_sync_source failed"); +} + +static DECLARE_WORK(tsc_sync_work, tsc_sync_mark_tsc_unstable); + /* * The freshly booted CPU initiates this via an async SMP function call. */ @@ -395,7 +403,7 @@ retry: "turning off TSC clock.\n", max_warp); if (random_warps) pr_warn("TSC warped randomly between CPUs\n"); - mark_tsc_unstable("check_tsc_sync_source failed"); + schedule_work(&tsc_sync_work); } =20 /*