Re: 回复: [External Mail][PATCH] tick/broadcast: Plug clockevents replacement race

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, Aug 28 2026 at 09:08, 刘术高 wrote:

Can you please adhere to the kernel mailing list netiquette:

  https://people.kernel.org/tglx/notes-about-netiquette

> 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

and to the documented process in Documentation/process/* which clearly
states that the way to confirm that a bug is fixed is expressed by a

Tested-by: ....

tag, which allows tools to pick it up automatically.

Thanks,

        tglx