Re: PATCH: Race in 2.6.0-test2 timer code

[Andrea Arcangeli <andrea@suse.de>]

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