Race condition when replacing the broadcast timer

We find a possible race condition when replacing the broadcast timer. Here is how the race happend,

1. In thread 0, ___tick_broadcast_oneshot_control, timer 0 as a broadcast timer is updating the next_event.

2. In thread 1, tick_install_broadcast_device, timer 0 is going to be replaced by a new timer 1.

3. If thread 0 gets the broadcast timer first, it would have the old timer returned (timer 0). When thread 1 shuts the old timer down and marks it as detached, Thread 0 still have the chance to re-enable the old timer with a noop handler if it executes slower than thread 1.

4. As the old timer is binded to a CPU, when plug out that CPU, kernel fails at clockevents.c:653

We find a possible race condition when replacing the broadcast timer. Here is how the race happend,

1. In thread 0, ___tick_broadcast_oneshot_control, timer 0 as a broadcast timer is updating the next_event.

2. In thread 1, tick_install_broadcast_device, timer 0 is going to be replaced by a new timer 1.

3. If thread 0 gets the broadcast timer first, it would have the old timer returned (timer 0). When thread 1 shuts the old timer down and marks it as detached, Thread 0 still have the chance to re-enable the old timer with a noop handler if it executes slower than thread 1.

4. As the old timer is binded to a CPU, when plug out that CPU, kernel fails at clockevents.c:653

Thanks for the fast reply.
May I know when there'll be a formal patch on the mainline?

-----Original Message-----
From: Thomas Gleixner <[email protected]>
Sent: Thursday, June 27, 2024 7:27 PM
To: 朱恺乾 <[email protected]>; Daniel Lezcano <[email protected]>
Cc: [email protected]; 王韬 <[email protected]>; 熊亮 <[email protected]>; [email protected]; Frederic Weisbecker <[email protected]>; Anna-Maria Behnsen <[email protected]>
Subject: [External Mail]Re: Race condition when replacing the broadcast timer

[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈

Quoted 9 lines · 朱恺乾

We find a possible race condition when replacing the broadcast timer. Here is how the race happend,

1. In thread 0, ___tick_broadcast_oneshot_control, timer 0 as a broadcast timer is updating the next_event.

2. In thread 1, tick_install_broadcast_device, timer 0 is going to be replaced by a new timer 1.

Quoted 7 lines

3. If thread 0 gets the broadcast timer first, it would have the old timer returned (timer 0). When thread 1 shuts the old timer down and marks it as detached, Thread 0 still have the chance to re-enable the old timer with a noop handler if it executes slower than thread 1.

4. As the old timer is binded to a CPU, when plug out that CPU, kernel fails at clockevents.c:653

Clearly tick_install_broadcast_device() lacks serialization.

The untested patch below should cure that.

Thanks,

tglx

---
  kernel/time/clockevents.c    |   31 +++++++++++++++++++------------
  kernel/time/tick-broadcast.c |   36 ++++++++++++++++++++++--------------
  kernel/time/tick-internal.h  |    2 ++
  3 files changed, 43 insertions(+), 26 deletions(-)

kernel/time/clockevents.c +17 -12

@@ -557,23 +557,14 @@ void clockevents_handle_noop(struct cloc  {  }
 
-/**
- * clockevents_exchange_device - release and request clock devices
- * @old:       device to release (can be NULL)
- * @new:       device to request (can be NULL)
- *
- * Called from various tick functions with clockevents_lock held and
- * interrupts disabled.
- */
-void clockevents_exchange_device(struct clock_event_device *old,
-                                struct clock_event_device *new)
+void __clockevents_exchange_device(struct clock_event_device *old,
+                                  struct clock_event_device *new)
  {
         /*
          * Caller releases a clock event device. We queue it into the
          * released list and do a notify add later.
          */
         if (old) {
-               module_put(old->owner);
                 clockevents_switch_state(old, CLOCK_EVT_STATE_DETACHED);
                 list_move(&old->list, &clockevents_released);
         }

@@ -585,6 +576,22 @@ void clockevents_exchange_device(struct
  }
 
  /**
+ * clockevents_exchange_device - release and request clock devices
+ * @old:       device to release (can be NULL)
+ * @new:       device to request (can be NULL)
+ *
+ * Called from various tick functions with clockevents_lock held and
+ * interrupts disabled.
+ */
+void clockevents_exchange_device(struct clock_event_device *old,
+                                struct clock_event_device *new) {
+       if (old)
+               module_put(old->owner);
+       __clockevents_exchange_device(old, new); }
+
+/**
   * clockevents_suspend - suspend clock devices
   */
  void clockevents_suspend(void)

@@ -650,7 +657,7 @@ void tick_cleanup_dead_cpu(int cpu)
                 if (cpumask_test_cpu(cpu, dev->cpumask) &&
                     cpumask_weight(dev->cpumask) == 1 &&
                     !tick_is_broadcast_device(dev)) {
-                       BUG_ON(!clockevent_state_detached(dev));
+                       WARN_ON(!clockevent_state_detached(dev));
                         list_del(&dev->list);
                 }
         }

kernel/time/tick-broadcast.c +24 -14

@@ -162,23 +162,31 @@ static bool tick_set_oneshot_wakeup_devi
   */
  void tick_install_broadcast_device(struct clock_event_device *dev, int cpu)  {
-       struct clock_event_device *cur = tick_broadcast_device.evtdev;
+       struct clock_event_device *cur;
 
-       if (tick_set_oneshot_wakeup_device(dev, cpu))
-               return;
+       scoped_guard(raw_spinlock_irqsave, &tick_broadcast_lock) {
 
-       if (!tick_check_broadcast_device(cur, dev))
-               return;
+               if (tick_set_oneshot_wakeup_device(dev, cpu))
+                       return;
 
-       if (!try_module_get(dev->owner))
-               return;
+               cur = tick_broadcast_device.evtdev;
+               if (!tick_check_broadcast_device(cur, dev))
+                       return;
 
-       clockevents_exchange_device(cur, dev);
+               if (!try_module_get(dev->owner))
+                       return;
+
+               __clockevents_exchange_device(cur, dev);
+               if (cur)
+                       cur->event_handler = clockevents_handle_noop;
+               WRITE_ONCE(tick_broadcast_device.evtdev, dev);
+               if (!cpumask_empty(tick_broadcast_mask))
+                       tick_broadcast_start_periodic(dev);
+       }
+
+       /* Module release must be outside of the lock */
         if (cur)
-               cur->event_handler = clockevents_handle_noop;
-       tick_broadcast_device.evtdev = dev;
-       if (!cpumask_empty(tick_broadcast_mask))
-               tick_broadcast_start_periodic(dev);
+               module_put(old->owner);
 
         if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT))
                 return;

@@ -1185,7 +1193,7 @@ int tick_broadcast_oneshot_active(void)
   */
  bool tick_broadcast_oneshot_available(void)
  {
-       struct clock_event_device *bc = tick_broadcast_device.evtdev;
+       struct clock_event_device *bc =
+ READ_ONCE(tick_broadcast_device.evtdev);
 
         return bc ? bc->features & CLOCK_EVT_FEAT_ONESHOT : false;  } @@ -1193,7 +1201,7 @@ bool tick_broadcast_oneshot_available(vo
  #else
  int __tick_broadcast_oneshot_control(enum tick_broadcast_state state)  {
-       struct clock_event_device *bc = tick_broadcast_device.evtdev;
+       struct clock_event_device *bc =
+ READ_ONCE(tick_broadcast_device.evtdev);
 
         if (!bc || (bc->features & CLOCK_EVT_FEAT_HRTIMER))
                 return -EBUSY;

kernel/time/tick-internal.h +3 -0

@@ -53,6 +53,8 @@ static inline void clockevent_set_state(  }
 
  extern void clockevents_shutdown(struct clock_event_device *dev);
+extern void __clockevents_exchange_device(struct clock_event_device *old,
+                                         struct clock_event_device
+*new);
  extern void clockevents_exchange_device(struct clock_event_device *old,
                                         struct clock_event_device *new);  extern void clockevents_switch_state(struct clock_event_device *dev,
 #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#

Thanks for the fast reply.
May I know when there'll be a formal patch on the mainline?

-----Original Message-----
From: Thomas Gleixner <[email protected]>
Sent: Thursday, June 27, 2024 7:27 PM
To: 朱恺乾 <[email protected]>; Daniel Lezcano <[email protected]>
Cc: [email protected]; 王韬 <[email protected]>; 熊亮 <[email protected]>; [email protected]; Frederic Weisbecker <[email protected]>; Anna-Maria Behnsen <[email protected]>
Subject: [External Mail]Re: Race condition when replacing the broadcast timer

[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈

Quoted 9 lines · 朱恺乾

We find a possible race condition when replacing the broadcast timer. Here is how the race happend,

1. In thread 0, ___tick_broadcast_oneshot_control, timer 0 as a broadcast timer is updating the next_event.

2. In thread 1, tick_install_broadcast_device, timer 0 is going to be replaced by a new timer 1.

Quoted 7 lines

3. If thread 0 gets the broadcast timer first, it would have the old timer returned (timer 0). When thread 1 shuts the old timer down and marks it as detached, Thread 0 still have the chance to re-enable the old timer with a noop handler if it executes slower than thread 1.

4. As the old timer is binded to a CPU, when plug out that CPU, kernel fails at clockevents.c:653

Clearly tick_install_broadcast_device() lacks serialization.

The untested patch below should cure that.

Thanks,

tglx

---
  kernel/time/clockevents.c    |   31 +++++++++++++++++++------------
  kernel/time/tick-broadcast.c |   36 ++++++++++++++++++++++--------------
  kernel/time/tick-internal.h  |    2 ++
  3 files changed, 43 insertions(+), 26 deletions(-)

kernel/time/clockevents.c +17 -12

@@ -557,23 +557,14 @@ void clockevents_handle_noop(struct cloc  {  }
 
-/**
- * clockevents_exchange_device - release and request clock devices
- * @old:       device to release (can be NULL)
- * @new:       device to request (can be NULL)
- *
- * Called from various tick functions with clockevents_lock held and
- * interrupts disabled.
- */
-void clockevents_exchange_device(struct clock_event_device *old,
-                                struct clock_event_device *new)
+void __clockevents_exchange_device(struct clock_event_device *old,
+                                  struct clock_event_device *new)
  {
         /*
          * Caller releases a clock event device. We queue it into the
          * released list and do a notify add later.
          */
         if (old) {
-               module_put(old->owner);
                 clockevents_switch_state(old, CLOCK_EVT_STATE_DETACHED);
                 list_move(&old->list, &clockevents_released);
         }

@@ -585,6 +576,22 @@ void clockevents_exchange_device(struct
  }
 
  /**
+ * clockevents_exchange_device - release and request clock devices
+ * @old:       device to release (can be NULL)
+ * @new:       device to request (can be NULL)
+ *
+ * Called from various tick functions with clockevents_lock held and
+ * interrupts disabled.
+ */
+void clockevents_exchange_device(struct clock_event_device *old,
+                                struct clock_event_device *new) {
+       if (old)
+               module_put(old->owner);
+       __clockevents_exchange_device(old, new); }
+
+/**
   * clockevents_suspend - suspend clock devices
   */
  void clockevents_suspend(void)

@@ -650,7 +657,7 @@ void tick_cleanup_dead_cpu(int cpu)
                 if (cpumask_test_cpu(cpu, dev->cpumask) &&
                     cpumask_weight(dev->cpumask) == 1 &&
                     !tick_is_broadcast_device(dev)) {
-                       BUG_ON(!clockevent_state_detached(dev));
+                       WARN_ON(!clockevent_state_detached(dev));
                         list_del(&dev->list);
                 }
         }

kernel/time/tick-broadcast.c +24 -14

@@ -162,23 +162,31 @@ static bool tick_set_oneshot_wakeup_devi
   */
  void tick_install_broadcast_device(struct clock_event_device *dev, int cpu)  {
-       struct clock_event_device *cur = tick_broadcast_device.evtdev;
+       struct clock_event_device *cur;
 
-       if (tick_set_oneshot_wakeup_device(dev, cpu))
-               return;
+       scoped_guard(raw_spinlock_irqsave, &tick_broadcast_lock) {
 
-       if (!tick_check_broadcast_device(cur, dev))
-               return;
+               if (tick_set_oneshot_wakeup_device(dev, cpu))
+                       return;
 
-       if (!try_module_get(dev->owner))
-               return;
+               cur = tick_broadcast_device.evtdev;
+               if (!tick_check_broadcast_device(cur, dev))
+                       return;
 
-       clockevents_exchange_device(cur, dev);
+               if (!try_module_get(dev->owner))
+                       return;
+
+               __clockevents_exchange_device(cur, dev);
+               if (cur)
+                       cur->event_handler = clockevents_handle_noop;
+               WRITE_ONCE(tick_broadcast_device.evtdev, dev);
+               if (!cpumask_empty(tick_broadcast_mask))
+                       tick_broadcast_start_periodic(dev);
+       }
+
+       /* Module release must be outside of the lock */
         if (cur)
-               cur->event_handler = clockevents_handle_noop;
-       tick_broadcast_device.evtdev = dev;
-       if (!cpumask_empty(tick_broadcast_mask))
-               tick_broadcast_start_periodic(dev);
+               module_put(old->owner);
 
         if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT))
                 return;

@@ -1185,7 +1193,7 @@ int tick_broadcast_oneshot_active(void)
   */
  bool tick_broadcast_oneshot_available(void)
  {
-       struct clock_event_device *bc = tick_broadcast_device.evtdev;
+       struct clock_event_device *bc =
+ READ_ONCE(tick_broadcast_device.evtdev);
 
         return bc ? bc->features & CLOCK_EVT_FEAT_ONESHOT : false;  } @@ -1193,7 +1201,7 @@ bool tick_broadcast_oneshot_available(vo
  #else
  int __tick_broadcast_oneshot_control(enum tick_broadcast_state state)  {
-       struct clock_event_device *bc = tick_broadcast_device.evtdev;
+       struct clock_event_device *bc =
+ READ_ONCE(tick_broadcast_device.evtdev);
 
         if (!bc || (bc->features & CLOCK_EVT_FEAT_HRTIMER))
                 return -EBUSY;

kernel/time/tick-internal.h +3 -0

@@ -53,6 +53,8 @@ static inline void clockevent_set_state(  }
 
  extern void clockevents_shutdown(struct clock_event_device *dev);
+extern void __clockevents_exchange_device(struct clock_event_device *old,
+                                         struct clock_event_device
+*new);
  extern void clockevents_exchange_device(struct clock_event_device *old,
                                         struct clock_event_device
 *new);  extern void clockevents_switch_state(struct clock_event_device

*dev, #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部

或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#

Jiawei,
Please update here when you have the test result

Quoted 2 lines · 朱恺乾

Jiawei,
Please update here when you have the test result

Any update on this?

朱恺乾 reported and decoded the following race condition when a broadcast device is replaced:

CPUA CPUB
__tick_broadcast_oneshot_control()

   bc = tick_broadcast_device.evtdev;
					tick_install_broadcast_device(dev)
        				clockevents_exchange_device(cur, dev)
					   shutdown(cur);
					   detach(cur);
					   cur->handler = noop;
					   tick_broadcast_device.evtdev = dev;

tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device.

If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state.

The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations.

The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation.

That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock.

Let clockevents_exchange_device() do both operations as before, but let the broadcast device code take the two step approach and do the device exchange under tick_broadcast_lock and drop the module reference count after releasing it.

Fixes f8381cba04ba ("[PATCH] tick-management: broadcast functionality")

Reported-by 朱恺乾 <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

---
 kernel/time/clockevents.c    |   33 ++++++++++++++++++++-------------
 kernel/time/tick-broadcast.c |   36 ++++++++++++++++++++++--------------
 kernel/time/tick-internal.h  |    2 ++
 3 files changed, 44 insertions(+), 27 deletions(-)

kernel/time/clockevents.c +0 -0

@@ -557,34 +557,41 @@ void clockevents_handle_noop(struct cloc

/**
+ * clockevents_exchange_device - release and request clock devices
+ * @old: device to release (can be NULL)
+ * @new: device to request (can be NULL)
+ *
+ * Called from various tick functions with clockevents_lock held and
+ * interrupts disabled.

朱恺乾 reported and decoded the following race condition when a broadcast device is replaced:

CPUA CPUB
__tick_broadcast_oneshot_control()

   bc = tick_broadcast_device.evtdev;
					tick_install_broadcast_device(dev)
        				clockevents_exchange_device(cur, dev)
					   shutdown(cur);
					   detach(cur);
					   cur->handler = noop;
					   tick_broadcast_device.evtdev = dev;

tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device.

If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state.

The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations.

The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation.

That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock.

Quoted 26 lines · Thomas Gleixner

朱恺乾 reported and decoded the following race condition when a broadcast device is replaced:

CPUA CPUB
__tick_broadcast_oneshot_control()

   bc = tick_broadcast_device.evtdev;
					tick_install_broadcast_device(dev)
        				clockevents_exchange_device(cur, dev)
					   shutdown(cur);
					   detach(cur);
					   cur->handler = noop;
					   tick_broadcast_device.evtdev = dev;

tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device.

If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state.

The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations.

The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation.

Quoted 4 lines

That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock.

The reason why the module reference can not be dropped while holding tick_broadcast_lock is not obvious though. What can go wrong?

Hi, I have a pixel 7, if I could be asked to backport this, then I'll be happy to, for the fix, add:

Reviewed-by Bradley Morgan <[email protected]>

Quoted 4 lines · Bradley Morgan

Hi, I have a pixel 7, if I could be asked to backport this, then I'll be happy to, for the fix, add:

Reviewed-by Bradley Morgan <[email protected]>

It would be helpful to respond to the actual patch and not to some arbitrary reply. That way you might avoid your tags to be overseen by tools.

Quoted 4 lines · Thomas Gleixner

Quoted 3 lines · Bradley Morgan

Hi, I have a pixel 7, if I could be asked to backport this, then I'll be happy to, for the fix, add:

Quoted 6 lines

Quoted 1 line

Reviewed-by Bradley Morgan <[email protected]>

It would be helpful to respond to the actual patch and not to some arbitrary reply. That way you might avoid your tags to be overseen by tools.

Sorry my mail client sometimes glitches,

Quoted 1 line · Bradley Morgan

On 5 September 2026 22:21:24 BST, Thomas Gleixner <[email protected]>

Quoted 2 lines · wrote:

Quoted 2 lines · Bradley Morgan

Quoted 1 line

Hi, I have a pixel 7, if I could be asked to backport this, then I'll

be

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

happy to, for the fix, add:

Reviewed-by Bradley Morgan <[email protected]>

It would be helpful to respond to the actual patch and not to some arbitrary reply. That way you might avoid your tags to be overseen by tools.

Quoted 1 line

Sorry my mail client sometimes glitches,

I fail to see how your mail client is responsible for you to hit reply on the wrong mail.

But what do I know about all these new fangled mail clients who decide on their own what to do. When this happens to me I'm 100% confident that _I_ got it wrong and not my mail client. Maybe I'm just too old-school.

Thanks,

tglx

Quoted 16 lines · Thomas Gleixner

Quoted 1 line · Bradley Morgan

On 5 September 2026 22:21:24 BST, Thomas Gleixner <[email protected]>

Quoted 2 lines · wrote:

Quoted 2 lines · Bradley Morgan

Quoted 1 line

Hi, I have a pixel 7, if I could be asked to backport this, then I'll

be

Quoted 9 lines

Quoted 8 lines

Quoted 3 lines

happy to, for the fix, add:

Reviewed-by Bradley Morgan <[email protected]>

It would be helpful to respond to the actual patch and not to some arbitrary reply. That way you might avoid your tags to be overseen by tools.

Sorry my mail client sometimes glitches,

Quoted 7 lines

I fail to see how your mail client is responsible for you to hit reply on the wrong mail.

But what do I know about all these new fangled mail clients who decide on their own what to do. When this happens to me I'm 100% confident that _I_ got it wrong and not my mail client. Maybe I'm just too old-school.

Remove Daniel too. Bounces.

Quoted 7 lines · Bradley Morgan

Quoted 5 lines · Thomas Gleixner

Quoted 1 line · Bradley Morgan

On 5 September 2026 22:21:24 BST, Thomas Gleixner <[email protected]>

Quoted 2 lines · wrote:

Quoted 2 lines · Bradley Morgan

Quoted 1 line

Hi, I have a pixel 7, if I could be asked to backport this, then

I'll

Quoted 11 lines

Quoted 11 lines

be

Quoted 9 lines

Quoted 8 lines

Quoted 3 lines

happy to, for the fix, add:

Reviewed-by Bradley Morgan <[email protected]>

It would be helpful to respond to the actual patch and not to some arbitrary reply. That way you might avoid your tags to be overseen by tools.

Sorry my mail client sometimes glitches,

Quoted 8 lines

Quoted 7 lines

I fail to see how your mail client is responsible for you to hit reply on the wrong mail.

But what do I know about all these new fangled mail clients who decide on their own what to do. When this happens to me I'm 100% confident that _I_ got it wrong and not my mail client. Maybe I'm just too old-school.

Remove Daniel too. Bounces.

Sorry no. That's not how this works

#1 An OOO response is purely informational and does not justify to
remove the recipient from the CC list just because

#2 A bouncing email address is of course a valid reason to remove
someone from CC, but it is a matter of courtesy in the context of the Linux kernel lists to lookup whether the person vansished from the planet or just changed the mail address. That's what the MAINTAINERS file is for.

The thread you responded to was from TWO years ago...

Aside of that you did not respond to my actual complaint about responding to a random reply instead of responding to the actual patch.

If you fail to review what the AI agent of your choice hallucinates then so be it, but don't be surprised that I'm going to put you on my ignore list as a consequence and recommend to all other maintainers to do so as well.

Thomas

Quoted 6 lines · Thomas Gleixner

Quoted 4 lines · Bradley Morgan

Hi, I have a pixel 7, if I could be asked to backport this, then I'll be happy to, for the fix, add:

Reviewed-by Bradley Morgan <[email protected]>

Quoted 4 lines

It would be helpful to respond to the actual patch and not to some arbitrary reply. That way you might avoid your tags to be overseen by tools.

Sorry my mail client sometimes glitches,

+Remove anna-maria, she's on leave, and she sends OOO email.

Could you please share the expected timeline for merging this fix into the mainline kernel? We have downstream products depending on this fix and would appreciate it if the merge could be expedited.

It took you more than fricking TWO YEARS to test and validate that patch and now that you finally came around to take care of it without following the documented process you expect me to merge it within a couple of days and preferrably expedite it and provide you the expected timeline because you have a business case.

Could you please share the expected timeline for merging this fix into the mainline kernel? We have downstream products depending on this fix and would appreciate it if the merge could be expedited.

We have verified this patch on our platform (kernel v6.18 / Android 17) and can confirm it resolves the race condition issue. The problem is that tick_install_broadcast_device() calls clockevents_exchange_device() to move the old device to the released list (setting it to DETACHED state), then updates tick_broadcast_device.evtdev to the new device — but this sequence is not protected by tick_broadcast_lock. The cpuidle/hrtimer paths can observe the old device in DETACHED state during this window, leading to unexpected behavior.

After applying the patch, the issue no longer reproduces under our concurrent CPU idle + clockevent device registration testing.

Could you please share the expected timeline for merging this fix into the mainline kernel? We have downstream products depending on this fix and would appreciate it if the merge could be expedited.

Test environment:
- Kernel: 6.18
- Platform: Android 17
- Test: Concurrent CPU idle + clockevent device registration