Re: [BUG] Race condition with it_real_fn in kernel/itimer.c
From: Steven Rostedt
Date: Wed Jun 15 2005 - 13:39:23 EST
On Wed, 2005-06-15 at 21:39 +0400, Oleg Nesterov wrote:
> Steven Rostedt wrote:
> >
> > + try_again:
> > spin_lock_irq(&tsk->sighand->siglock);
> > interval = tsk->signal->it_real_incr;
> > val = it_real_value(tsk->signal);
> > - if (val)
> > + if (val) {
> > + spin_unlock_irq(&tsk->sighand->siglock);
> > del_timer_sync(&tsk->signal->real_timer);
> > + goto try_again;
>
> I think we don't need del_timer_sync() at all, just del_timer().
>
> Because it_real_value() returns 0 when timer is not pending. And
> in this case the timer may still be running, but do_setitimer()
> doesn't call del_timer_sync().
OK, so is this the better patch?
[Andrew, do NOT use the following]
--- linux-2.6.12-rc6/kernel/itimer.c.orig 2005-06-15 12:14:13.000000000 -0400
+++ linux-2.6.12-rc6/kernel/itimer.c 2005-06-15 14:06:23.000000000 -0400
@@ -157,7 +157,7 @@
interval = tsk->signal->it_real_incr;
val = it_real_value(tsk->signal);
if (val)
- del_timer_sync(&tsk->signal->real_timer);
+ del_timer(&tsk->signal->real_timer);
tsk->signal->it_real_incr =
timeval_to_jiffies(&value->it_interval);
it_real_arm(tsk, timeval_to_jiffies(&value->it_value));
I haven't played too much with the itimer, what harm can happen if the
timer is running while this is deleted? [examines code here] This also
looks bad. Since the softirq function can be running and then call
it_real_arm unprotected! And you can see here that it_real_arm is also
called and they both call add_timer! This would not work, so far the
first patch seems to handle this.
-- Steve
PS. Don't strip the CC list.
-
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/