(this patch too has been forgotten. It fixes the same issue in ondemandas we find in the very very similar (read : cut and pasted) conservativecpufreq code). It applies to mainline head and -stable kernels.

The problem is that dbs_timer_exit() uses cancel_delayed_work() when it shoulduse cancel_delayed_work_sync(). cancel_delayed_work() does not wait for theworkqueue handler to exit.

The ondemand governor does not "seem" to be affected (read : racecondition occurs very rarely) because the "if (!dbs_info->enable)" checkat the beginning of the workqueue handler returns immediately withoutrescheduling the work. The conservative governor in 2.6.30-rc has thesame check as the ondemand governor, which makes things usually runsmoothly. However, if the governor is quickly stopped and then started,this could lead to the following race :dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.This is why a synchronized teardown is required.

The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.