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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Jul 2008 09:12:55 +0530
From:	Nageswara R Sastry <rnsastry@...ux.vnet.ibm.com>
To:	Johannes Weiner <hannes@...urebad.de>
CC:	linux-kernel@...r.kernel.org, balbir@...ux.vnet.ibm.com,
	ego@...ux.vnet.ibm.com, svaidy@...ux.vnet.ibm.com,
	davej@...emonkey.org.uk, pzijlstr@...hat.com
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@...urebad.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@...ux.vnet.ibm.com>
Signed-off-by: Johannes Weiner <hannes@...urebad.de>
---


---
From: Johannes Weiner <hannes@...urebad.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@...urebad.de>
---

Thanks

Regards
R.Nageswara Sastry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/