>If the timer was already pending, you have just DESTROYED its expires
>value. This means you have no control over when it will expire at all,
I don' t want to have control on its exipres value. Look at
do_getitimer(). At do_getitimer() runtime, the other CPU could
be running it_real_fn() and so we could have the same timer inserted two
times in the timer list. This is the _only_ reason for adding that check.
The other way is running the del_timer in do_getitimer() in a bh atomic
context, but my way was more efficient because it would block nothing.
>since the timer needs to be in the correct timer vector to expire when it
>should. It can also mess up cascade_timers slightly (this can and should
>be fixed though).
Argg, I see it now. This because if the timer->expires is been changed
from another function we could rinsert the timer in the vector that is
going to be flushed (and so we would never run the timer). This is not the
case of getitimer, but it could be for setitimer...
>The solution is to use mod_timer instead, it does everything necessary, so
>if there is a race anywhere, replace
>
>"timer->expires = x; add_timer(x);" with "mod_timer(timer, x);"
Yes, probably the right thing to do is to only add the start_bh_atomic()
around all del_timer() in itimer.c and not touch the timer code as I did.
Thanks.
>What's the rationale for that change? Seems buggy to me, you risk having a
A bad thought ;-). Is buggy.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/