[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 27.09.17 at 12:18, <dario.faggioli@xxxxxxxxxx> wrote:
> On Wed, 2017-09-27 at 02:20 -0600, Jan Beulich wrote:
>> In the end what I think I'm missing is a clear description of an
>> actual
>> case where the current behavior causes breakage (plus of course
>> an explanation why the new behavior is unlikely to cause issues with
>> existing users).
> So, the problem is that the handler of the RCU idle_timer, introduced
> by 2b936ea7b716dc1a13c ("xen: RCU: avoid busy waiting until the end of
> grace period."), never runs.
> 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. 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)?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.