* Ingo Molnar (mingo@xxxxxxx) wrote: > > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Thu, 23 Apr 2009 10:00:02 -0400 > > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx> wrote: > > > > > ODEBUG: init active object type: timer_list > > > It seems to be complaining that cpufreq_governor_dbs() is running > > init_timer() against a timer which has already been initialised > > once. > > Not just already initialized - but also active. There's these states > for an object: > > ODEBUG_STATE_NONE, > ODEBUG_STATE_INIT, > ODEBUG_STATE_INACTIVE, > ODEBUG_STATE_ACTIVE, > ODEBUG_STATE_DESTROYED, > > So the 'init active object type' warning above suggests that an > init_timer() has been done on an already running timer. If true then > that is a bad bug - can corrupt timer state, etc. > > Thomas, do you agree? > This would fit with the behavior I've noticed and submitted a patch for later in this thread. Basically, the incorrect use of "cancel_delayed_work()" instead of "cancel_delayed_work_sync()" may leave the timer active if the race explained in the mail below happen. http://lkml.org/lkml/2009/4/24/19 Maybe we should audit other users of schedule_delayed_work/cancel_delayed_work that are re-arming themselves in the workqueue handler without any proper cancel_delayed_work_sync() nor flush_workqueue() calls on teardown. Mathieu > Ingo -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
