Re: [BUG] While changing the cpufreq governor, kernel hits a bug in workqueue.c

[Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>]

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