Re: [patch 2/2] hrtimer

[Thomas Gleixner]

On Sat, 2006-03-25 at 18:32 -0800, Andrew Morton wrote:

> This all looks vaguely racy.  hrtimer_wakeup() will set t->task to NULL
> without barriers, locks or anything.  And the waiter here can break out of
> schedule() due to signal delivery while a wakeup is in progress.

We set task = NULL before wake_up_process() which acts as a barrier.

> So the value of t->task here is fairly meaningless.  Ot just depends on how
> far the waker has got through hrtimer_wakeup().
> 
> Maybe that doesn't matter, because hrtimer_cancel() will spin until
> hrtimer_wakeup() has completed anyway, but could you please recheck and
> confirm that this is all solid?

Right, either it waits for the running timer or in case the wakeup
happens between

if (unlikely(t->task)) {

and

	hrtimer_cancel(&t->timer);

then hrtimer_cancel will see that the timer is inactive and we drop out
of the loop because the while(t->task) condition is not longer true. 

	tglx



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/