Re: [RFC 2/7] hrtimer: don't check for active hrtimer after adding it

[Chris Redpath <Chris.Redpath@arm.com>]

Hi Viresh,

On 09/07/14 07:55, Viresh Kumar wrote:
> hrtimer_start*() family never fails to enqueue a hrtimer to a clock-base. The
> only special case is when the hrtimer was in past. If it is getting enqueued to
> local CPUs's clock-base, we raise a softirq and exit, else we handle that on
> next interrupt on remote CPU.
>
> At several places in the kernel, we try to make sure if hrtimer was added
> properly or not by calling hrtimer_active(), like:
>
> 	hrtimer_start(timer, expires, mode);
> 	if (hrtimer_active(timer)) {
> 		/* Added successfully */
> 	} else {
> 		/* Was added in the past */
> 	}
>
> As hrtimer_start*() never fails, hrtimer_active() is guaranteed to return '1'.
> So, there is no point calling hrtimer_active().
>
> This patch updates hrtimer core to get this fixed.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>   kernel/hrtimer.c | 4 ----
>   1 file changed, 4 deletions(-)
>
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index cf40209..a76f962 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -1555,8 +1555,6 @@ static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode mod
>   	do {
>   		set_current_state(TASK_INTERRUPTIBLE);
>   		hrtimer_start_expires(&t->timer, mode);
> -		if (!hrtimer_active(&t->timer))
> -			t->task = NULL;
>
>   		if (likely(t->task))
>   			freezable_schedule();
> @@ -1837,8 +1835,6 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned long delta,
>   	hrtimer_init_sleeper(&t, current);
>
>   	hrtimer_start_expires(&t.timer, mode);
> -	if (!hrtimer_active(&t.timer))
> -		t.task = NULL;
>
>   	if (likely(t.task))
>   		schedule();
>

Maybe safe to remove this if condition too.