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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:44 EST