linux-kernel - Re: [PATCH 2/2] cpufreq: serialize calls to __cpufreq

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:	Wed, 04 Sep 2013 17:54:50 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] cpufreq: serialize calls to __cpufreq_governor()

On 09/04/13 17:26, Rafael J. Wysocki wrote:
> On Wednesday, September 04, 2013 04:50:01 PM Stephen Boyd wrote:
>> On 09/04/13 16:55, Rafael J. Wysocki wrote:
>>> Well, I'm not sure when Viresh is going to be back.
>>>
>>> Srivatsa, can you please resend this patch with a proper changelog?
>>>
>> I haven't had a chance to try this out yet, but I was just thinking
>> about this patch. How is it going to work? If one task opens the file
>> and another task is taking down the CPU wouldn't we deadlock in the
>> CPU_DOWN notifier waiting for the kobject to be released? Task 1 will
>> grab the kobject reference and sleep on the hotplug mutex and task 2
>> will put the kobject and wait for the completion, but it won't happen.
>> At least I think that's what would happen.
> Do you mean the completion in sysfs_deactivate()?  Yes, we can deadlock
> there.

I mean the complete in cpufreq_sysfs_release(). I don't think that will
ever be called because the kobject is held by the task calling store()
which is waiting on the hotplug lock to be released.

>
> Well, I guess the Srivatsa's patch may be salvaged by making it do a "trylock"
> version of get_online_cpus(), but then I wonder if there's no better way.

I think the real solution is to remove the kobject first if the CPU
going down is the last user of that policy. Once the completion is done
we can stop the governor and clean up state. For the case where there
are still CPUs using the policy why can't we cancel that CPU's work and
do nothing else? Even in the case where we have to move the cpufreq
directory do we need to do a STOP/START/LIMITS sequence? I hope we can
get away with just moving the directory and canceling that CPUs work then.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
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/