linux-kernel - [tip: timers/urgent] tick/broadcast: Move per CPU pointer access into the atomic section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <172242252292.2215.8458613461295137284.tip-bot2@tip-bot2>
Date: Wed, 31 Jul 2024 10:42:02 -0000
From: "tip-bot2 for Thomas Gleixner" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: David Wang <00107082@....com>, Thomas Gleixner <tglx@...utronix.de>,
 Yu Liao <liaoyu15@...wei.com>, stable@...r.kernel.org, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: [tip: timers/urgent] tick/broadcast: Move per CPU pointer access into
 the atomic section

The following commit has been merged into the timers/urgent branch of tip:

Commit-ID:     6881e75237a84093d0986f56223db3724619f26e
Gitweb:        https://git.kernel.org/tip/6881e75237a84093d0986f56223db3724619f26e
Author:        Thomas Gleixner <tglx@...utronix.de>
AuthorDate:    Wed, 31 Jul 2024 12:23:51 +02:00
Committer:     Thomas Gleixner <tglx@...utronix.de>
CommitterDate: Wed, 31 Jul 2024 12:37:43 +02:00

tick/broadcast: Move per CPU pointer access into the atomic section

The recent fix for making the take over of the broadcast timer more
reliable retrieves a per CPU pointer in preemptible context.

This went unnoticed as compilers hoist the access into the non-preemptible
region where the pointer is actually used. But of course it's valid that
the compiler keeps it at the place where the code puts it which rightfully
triggers:

  BUG: using smp_processor_id() in preemptible [00000000] code:
       caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0

Move it to the actual usage site which is in a non-preemptible region.

Fixes: f7d43dd206e7 ("tick/broadcast: Make takeover of broadcast hrtimer reliable")
Reported-by: David Wang <00107082@....com>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Tested-by: Yu Liao <liaoyu15@...wei.com>
Cc: stable@...r.kernel.org
Link: https://lore.kernel.org/all/87ttg56ers.ffs@tglx
---
 kernel/time/tick-broadcast.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index b484309..ed58eeb 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -1141,7 +1141,6 @@ void tick_broadcast_switch_to_oneshot(void)
 #ifdef CONFIG_HOTPLUG_CPU
 void hotplug_cpu__broadcast_tick_pull(int deadcpu)
 {
-	struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
 	struct clock_event_device *bc;
 	unsigned long flags;
 
@@ -1167,6 +1166,8 @@ void hotplug_cpu__broadcast_tick_pull(int deadcpu)
 		 * device to avoid the starvation.
 		 */
 		if (tick_check_broadcast_expired()) {
+			struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
+
 			cpumask_clear_cpu(smp_processor_id(), tick_broadcast_force_mask);
 			tick_program_event(td->evtdev->next_event, 1);
 		}