Re: PATCH: Race in 2.6.0-test2 timer code

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Jul 30, 2003 at 01:49:52PM +0200, Ingo Molnar wrote:
> 
> On Wed, 30 Jul 2003, Andrea Arcangeli wrote:
> 
> > in del_timer, list_del can be reordered after the timer->base = NULL,
> > the C compiler can do that. so list_del will run at the same time of
> > internal_add_timer(base, timer) that does the list_add_tail.
> 
> no, it cannot run at the same time. The add_timer() will first lock the
> current CPU's base, before touching the list. Any parallel del_timer() can
> only do the list_del() if it first has locked timer->base. timer->base can
> only have the base of the CPU where it_real_fn is running, or be NULL. In
> the NULL case del_timer() wont do a thing but return. In the other case
> the timer->base value observed by the del_timer()-executing CPU will be
> the same base as where it_real_fn is running, so both the add_timer() and
> the del_timer() will serialize on the same base => no parallel list
> handling possible. How the compiler (or even the CPU, on non-x86) orders
> the writes within the locked section is irrelevant in this scenario.

so if it was really the itimer, it had to be on ppc s390 or ia64, not on
x86.  I never reproduced this myself. I will ask more info on bugzilla,
because I thought it was x86 but maybe it wasn't. As said in the
previous email, only non x86 archs can run the timer irq on a cpu
different than the one where it was inserted.

As Andrew, noted the same race could happen in 2.6 with add_timer_on.
But apparently you're right that the setitimer couldn't trigger on 2.6
or 2.4-aa x86.

Still it could be something else that broke related to
add_timer/del_timer_sync in drivers reproducible in x86 too. As said I
didn't debug or reproduce it myself. It simply looked correct to allow
add_timer to run in parallel of del_timer_sync (no matter which cpu
they're running on, if add_timer runs from inside the timer itself, of
course it can't trigger because the base won't change in add_timer and
del_timer will be a reader falling in the same base, but that's a kind
of special case, and it fails too if you use add_timer_on).

Andrea