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 D49191EF391; Tue, 22 Apr 2025 02:16:10 +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=1745288170; cv=none; b=YIZGO9F5S3XfrK+rF8ZXMglxbGX1hm9fy5M9hD+zVKwJF4MeDPom7ajm2bYBW/VsrT0ZyS1t0QmdC6bBBbeD8h7sUFGyAUzL9XCbwHnIZ9dkd+9pGqF5AmzYsKlPISpXIk7eszVGDkiax9EA2XyzrNCvLO+c9KhIxaqMHL5qbhc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745288170; c=relaxed/simple; bh=R/zYyScGBky2sOpDAf0q2XG2hiACRKTyjcFhCE+ct5M=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=tRY5LGPmItVBoQcVYQG25BtolFuSgNBaNVo4APdDrSZBMqqNRYD31O5y4fQHpyNxSJs/N1sX5SIuQv+w4uVhicojwfyEeWmk24+wHoYEoq8wX4Go54UeVgCHuqKLts78eyOOv/8hhpuJa4HqESaBDHvcAsgpYN1mPJS8BPheex0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O4wflveo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O4wflveo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74F30C4AF0C; Tue, 22 Apr 2025 02:16:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745288170; bh=R/zYyScGBky2sOpDAf0q2XG2hiACRKTyjcFhCE+ct5M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O4wflveoAvsGuUO9+fr+ZCIHKQpoIkkayqTojbogg9O6dI2P18plMS5wIzhvCvAl5 K0S1Ij+M/70iHUpok3XeaC4Ky/I7omuXMJx+fUPwNYU6BSPQpXiS6uX+8pHslU9evL O3A2BmvYU/xu68NDL+200Erq4O/10AM2frw+soJ7/nwZ3UB41WYcpY8Lj/91C2tkOo r39CDNgsLpbIZn+YhRLeMPXHQ5oyt3gzyJ12GvsVfnSL564s90Q0fS9VR8s7QGAfHL wQXUkmZhqfEpraiAVWTlvzht0CuFUy5Yd74iMrGf3sxYIuvNoz4FM5wdfQpnNrhVfX 3ocfCT7dWA+xA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Fernando Fernandez Mancera , Thomas Gleixner , Ingo Molnar , Sasha Levin , mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, dwmw@amazon.co.uk Subject: [PATCH AUTOSEL 6.14 09/30] x86/i8253: Call clockevent_i8253_disable() with interrupts disabled Date: Mon, 21 Apr 2025 22:15:29 -0400 Message-Id: <20250422021550.1940809-9-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250422021550.1940809-1-sashal@kernel.org> References: <20250422021550.1940809-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.14.3 Content-Transfer-Encoding: 8bit From: Fernando Fernandez Mancera [ Upstream commit 3940f5349b476197fb079c5aa19c9a988de64efb ] There's a lockdep false positive warning related to i8253_lock: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ... systemd-sleep/3324 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: ffffffffb2c23398 (i8253_lock){+.+.}-{2:2}, at: pcspkr_event+0x3f/0xe0 [pcspkr] ... ... which became HARDIRQ-irq-unsafe at: ... lock_acquire+0xd0/0x2f0 _raw_spin_lock+0x30/0x40 clockevent_i8253_disable+0x1c/0x60 pit_timer_init+0x25/0x50 hpet_time_init+0x46/0x50 x86_late_time_init+0x1b/0x40 start_kernel+0x962/0xa00 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0xed/0xf0 common_startup_64+0x13e/0x141 ... Lockdep complains due pit_timer_init() using the lock in an IRQ-unsafe fashion, but it's a false positive, because there is no deadlock possible at that point due to init ordering: at the point where pit_timer_init() is called there is no other possible usage of i8253_lock because the system is still in the very early boot stage with no interrupts. But in any case, pit_timer_init() should disable interrupts before calling clockevent_i8253_disable() out of general principle, and to keep lockdep working even in this scenario. Use scoped_guard() for that, as suggested by Thomas Gleixner. [ mingo: Cleaned up the changelog. ] Suggested-by: Thomas Gleixner Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Ingo Molnar Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/Z-uwd4Bnn7FcCShX@gmail.com Signed-off-by: Sasha Levin --- arch/x86/kernel/i8253.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/i8253.c b/arch/x86/kernel/i8253.c index 80e262bb627fe..cb9852ad60989 100644 --- a/arch/x86/kernel/i8253.c +++ b/arch/x86/kernel/i8253.c @@ -46,7 +46,8 @@ bool __init pit_timer_init(void) * VMMs otherwise steal CPU time just to pointlessly waggle * the (masked) IRQ. */ - clockevent_i8253_disable(); + scoped_guard(irq) + clockevent_i8253_disable(); return false; } clockevent_i8253_init(true); -- 2.39.5