Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 30 Jul 2003 13:28:19 +0200 | From | Andrea Arcangeli <> | Subject | Re: PATCH: Race in 2.6.0-test2 timer code |
| |
On Wed, Jul 30, 2003 at 03:51:40AM -0700, Andrew Morton wrote: > Ingo Molnar <mingo@elte.hu> wrote: > > > > But on 2.6 the timer will run precisely on the CPU it was added, so i > > think the race is not possible. > > well there is add_timer_on()... > > I still don't see the race in the itimer code actually. On return > from del_timer_sync() we know that the timer is not pending, even > if it_real_fn() tried to re-add it. > > ie: why does the below "crash"? > > > Andrea Arcangeli <andrea@suse.de> wrote: > > > > cpu0 cpu1 > > ------------ -------------------- > > > > do_setitimer > > it_real_fn > > del_timer_sync add_timer -> crash > > > (Does the timer_pending() test in del_timer_sync() needs some > barriers btw?)
it might be possible to use ordered writes on one side and ordered reads on the other side to fix this instead of spinlock. I suggested to use my spinlock-by-hand idea to fix it in 2.4 (like I previously did with mod_timer), but we might try to do something more efficient in 2.6 if you've some idea. I don't think it matters much anyways since the cacheline wouldn't be exlusive anyways if we get into the above path, and the above isn't the common path, but maybe it does. I think the unified way of locking with mod_timer/add_timer/del_timer I'm currently used is simple and clean, but if you see any significant performance advantage we can change it of course.
If my last email where I analyzed the problem in more detail is not clear or you see fault please let me know of course.
thanks,
Andrea - 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/
| ![\](/images/icornerr.gif) |