On 07/09/2014 10:57 AM, Viresh Kumar wrote:
On 9 July 2014 10:49, Preeti U Murthy preeti@linux.vnet.ibm.com wrote:
Is it possible that between the time we start the hrtimer and we check for hrtimer_active(), we can get a timer interrupt which can dequeue the tick sched timer if it were to be in the past? In this case the hrtimer_active() can have a failed return value right?
Most of the programming for tick-sched is done from interrupt-context and so interrupts might be disabled then.
Also, the checks in tick-sched and other kernel layers are not for checking if hrtimer is still enqueued or not. It is for checking if it was added in past.
My concern is around this comment itself. This function is not actually verifying if the timer was in the past. And such timers are taken care of in hrtimer_start* as you have pointed out.
So as we discussed offline, it would be good to mention in the changelog that currently in the kernel, this comment does not make sense for the above mentioned reason, in addition to saying that it will fail all the time in its find for a non-enqueued hrtimer.
Else the patch looks fine to me. I have added my reviewed by just in case Frederic intends to pick this up through his tree.
Reviewed-by: Preeti U Murthy preeti@linux.vnet.ibm.com
Regards Preeti U Murthy
And in case it is added in past, we will raise a softirq and quit. And would be handled on next interrupt..