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
| ||
|
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/
Powered by blists - more mailing lists