Re: [Xen-devel] [PATCH 1/3] xen: timers: don't miss a timer event because of stop_timer()

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Wed, 2017-09-27 at 04:30 -0600, Jan Beulich wrote:
> > > > On 27.09.17 at 12:18, <dario.faggioli@xxxxxxxxxx> wrote:
> 
> > And that is because the following happens:
> > - the CPU wants to go idle
> > - sched_tick_suspend()
> >     rcu_idle_timer_start()
> >       set_timer(RCU_idle_timer)
> > - the CPU goes idle
> >   ... ... ...
> > - RCU_idle_timer's IRQ arrives
> > - the CPU wakes up
> > - raise_softirq(TIMER_SOFTIRQ)
> > - sched_tick_resume()
> >     rcu_idle_timer_stop()
> >       stop_timer(RCU_idle_timer)
> >         deactivate_timer(RCU_idle_timer)
> >           remove_entry(RCU_idle_timer) // timer out of heap/list
> > - do_softirq() (we are inside idle_loop())
> > - softirq_handlers[TIMER_SOFTIRQ]()
> > - timer_softirq_action()
> >     // but the timer is not in the heap/list!
> 
> But this is an extremely special case, not something likely to
> happen anywhere else. Hence I wonder whether it wouldn't
> be better to handle the special case in a special way, rather
> than making generic code fit the special case.
>
Well, yes. As said, this "new" timer is the first, and for now the
only, that follow this pattern. And I also agree that this is not
something we must expect to see to happen much more (if at all).

Still, I continue to think that with a timer already expired, its IRQ
already delivered and handled and the relative TIMER_SOFTIRQ already
risen, we should arrange for the timer handler to run, in the general
case.

>  Or wait -
> wouldn't all you need be to avoid calling stop_timer() in the
> call tree above, if the timer's expiry has passed (suitably
> explained in a comment)?
> 
Yes. For the reason stated above, I addressed the problem at the
generic code level. If that doesn't fly, I'll do like this. I had
thought about that, and although I haven't tried, I think it works for
this case.

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel