Messages in this thread | | | Date | Wed, 30 Jul 2003 14:34:58 +0200 | From | Andrea Arcangeli <> | Subject | Re: PATCH: Race in 2.6.0-test2 timer code |
| |
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 - 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/
| |