linux-kernel - Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency

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:	Thu, 30 Nov 2006 09:58:07 +0530
From:	Gautham R Shenoy <ego@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	ego@...ibm.com, mingo@...e.hu, linux-kernel@...r.kernel.org,
	torvalds@...l.org, davej@...hat.com, dipankar@...ibm.com,
	vatsa@...ibm.com
Subject: Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency

On Wed, Nov 29, 2006 at 01:05:56PM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 20:54:04 +0530
> Gautham R Shenoy <ego@...ibm.com> wrote:
> 
> > Ok, so to cut the long story short,
> > - While changing governor from anything to
> > ondemand, locks are taken in the following order
> >
> > policy->lock ===> dbs_mutex ===> workqueue_mutex.

> >
> > - While offlining a cpu, locks are taken in the following order
> >
> > cpu_add_remove_lock ==> sched_hotcpu_mutex ==> workqueue_mutex ==
> > ==> cache_chain_mutex ==> policy->lock.
> 
> What functions are taking all these locks?  (ie: the callpath?)

While changing cpufreq governor to ondemand, the locks taken are:
--------------------------------------------------------------------------
lock		function		file
--------------------------------------------------------------------------
policy->lock	store_scaling_governor	drivers/cpufreq/cpufreq.c

dbs_mutex	cpufreq_governor_dbs	drivers/cpufreq/cpufreq_ondemand.c

workqueue_mutex	__create_workqueue	kernel/workqueue.c
--------------------------------------------------------------------------

The complete callpath would be

store_scaling_governor [*]
	|
__cpufreq_set_policy
	|
__cpufreq_governor(data, CPUFREQ_GOV_START)
	|
policy->governor->governor => cpufreq_governor_dbs(data, CPUFREQ_GOV_START) [*]
	|
create_workqueue #defined as __create_workqueue [*]
	
where [*] = locks taken.

While offlining a cpu, locks are taken in the following order:

--------------------------------------------------------------------------
lock			function		file
--------------------------------------------------------------------------
cpu_add_remove_lock	cpu_down		kernel/cpu.c

sched_hotcpu_mutex	migration_call		kernel/sched.c

workqueue_mutex		workqueue_cpu_callback	kernel/workqueue.c

cache_chain_mutex	cpuup_callback		mm/slab.c

policy->lock		cpufreq_driver_target	drivers/cpufreq/cpufreq.c
---------------------------------------------------------------------------

Please note that in the above,
- sched_hotcpu_mutex, workqueue_mutex, cache_chain_mutex are taken 
  while handling CPU_LOCK_ACQUIRE events in the respective subsystems'
  cpu_callback functions.

- policy->lock is taken while handling CPU_DOWN_PREPARE in 
  cpufreq_cpu_callback which calls cpufreq_driver_target.

It's perfectly clear that in the cpu offline callpath, cpufreq
does not have to do anything with the workqueue. 

So can we ignore this circular-dep warning as a false positive?
Or is there a way to exploit this circular dependency ?

At the moment, I cannot think of way to exploit this circular dependency
unless we do something like try destroying the created workqueue when the
cpu is dead, i.e make the cpufreq governors cpu-hotplug-aware.
(eeks! that doesn't look good)

I'm working on fixing this. Let me see if I can come up with something.

Thanks and Regards
gautham.
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
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/