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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
