Messages in this thread | | | Date | Tue, 2 Sep 2003 08:33:50 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [PATCH] Race condition in del_timer_sync (2.5) |
| |
On Tue, 2 Sep 2003, Tejun Huh wrote:
> This patch fixes a race between del_timer_sync and recursive timers. > Current implementation allows the value of timer->base that is used for > timer_pending test to be fetched before finishing running_timer test, so > it's possible for a recursive time to be pending after del_timer_sync. > Adding smp_rmb before timer_pending removes the race.
good catch. Have you ever trigger this bug, or did you find it via code review?
just to explore the scope of this problem a bit more: at first glance all other timer_pending() uses seem to be safe. del_timer_sync()'s timer_pending() use is special, because it's next to the ->running_timer check without any barriers inbetween - so we could indeed in theory end up with having the two reads reordered and a freshly added timer (on another CPU) not being recognized properly. Also, this is the only timer API call that guarantees the complete stopping of a timer.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |