Messages in this thread | | | Date | Tue, 15 Jul 2008 09:12:55 +0530 | From | Nageswara R Sastry <> | Subject | Re: [BUG] While changing the cpufreq governor, kernel hits a bug in workqueue.c |
| |
Johannes Weiner wrote: > Hi, > > [added Peter on CC, lockdep confuses me] > Hmmm, it's weird. This path should be okay. I wonder where the > dependency work -> dbs_mutex comes from. The mutex is nowhere taken > with the work lock held (I removed this in the new version of the patch, > can you double-check you applied to correct patch?). > > So the chain should really be dbs_mutex -> work-lock. > > > Uhm, this dependency is as new as the actual lockdep detection (the same > backtrace as the whole event, see below). What is lockdep doing here? > Shouldn't this be the callpath where the lock was taken for the first > time? > > I can not see where the chain is ever work-lock -> dbs_mutex, so how > does lockdep come to the conclusion this would be the correct order? >
I confirm that Linux kernel patched with the following patches.
-- From: Johannes Weiner <hannes@saeurebad.de> Subject: cpufreq: cancel self-rearming work synchroneously
The ondemand and conservative governor workers are self-rearming. Cancel them synchroneously to avoid nasty races.
This patch also removes taking a mutex in the conservative worker function as the locking is dbs_mutex -> work and not the other way round.
Reported-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: Johannes Weiner <hannes@saeurebad.de> ---
--- From: Johannes Weiner <hannes@saeurebad.de> Subject: cpufreq: Fix race in enabling ondemand/conservative governors
Prevent double activation of the governor if two processes race on the check for whether the governor is already active.
Signed-off-by: Johannes Weiner <hannes@saeurebad.de> ---
Thanks
Regards R.Nageswara Sastry
| |