Messages in this thread | | | Date | Thu, 22 Jan 2015 12:15:36 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH V3] tick/broadcast: Make movement of broadcast hrtimer robust against hotplug |
| |
On Thu, 22 Jan 2015, Preeti U Murthy wrote: > On 01/21/2015 05:16 PM, Thomas Gleixner wrote: > How about when the cpu that is going offline receives a timer interrupt > just before setting its state to CPU_DEAD ? That is still possible right > given that its clock devices may not have been shutdown and it is > capable of receiving interrupts for a short duration. Even with the > above patch, is the following scenario possible ? > > CPU0 CPU1 > t0 Receives timer interrupt > > t1 Sees that there are hrtimers > to be serviced (hrtimers are not yet migrated) > > t2 calls hrtimer_interrupt() > > t3 tick_program_event() CPU_DEAD notifiers > CPU0's td->evtdev = NULL > > t4 clockevent_program_event() > references NULL tick device pointer > > So my concern is that since the CLOCK_EVT_NOTIFY_CPU_DEAD callback > handles shutting down of devices besides moving tick related duties. > it's functions may race with the hotplug cpu still handling tick events.
__cpu_disable() is supposed to block interrupts on the dying cpu.
But I agree, we should make it more robust. So we want an explicit call for disabling the cpu local stuff and an explicit takeover of the broadcast duty. I'm anyway distangling the clockevents_notify() stuff, so it should be simple to do so.
Thanks,
tglx
| |