On Thu, 12 Nov 2026 08:35:16 +0000, sashiko-bot@kernel.org wrote:
> This fixes a bug in the two-step vector move synchronization and local
> retry timer.  Should it include a Fixes tag?

Yes, will add.

[...]

> Does calling imsic_remote_kick(mvec->cpu) here wake the destination CPU
> out of cpuidle right after it takes over the broadcast timer?
Yes, by design. Only the new CPU clears move_prev, so it has to run
once after the old CPU is done. The retry timer did the same a jiffy
later.

> Until CPU1 re-enables IRQs and services the IPI,
> new_vec->move_prev remains non-NULL, so if a third CPU enters
> tick_broadcast_enter() with an earlier expiry during that window,
> imsic_irq_set_affinity() still sees imsic_vector_get_move() != NULL and
> returns -EBUSY.
The pending IPI ends idle at once, so the window is the idle exit
latency. The broadcast IRQ then stays on CPU1, whose handler still
wakes the third CPU in time.

> kicking new_vec->cpu twice.
irq_work_queue_on() skips a work that is still pending, so this costs
at most one extra IPI.

-- 
Troy Mitchell