linux-kernel - Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

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, 5 Aug 2014 11:44:21 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Saravana Kannan <skannan@...eaurora.org>
Cc:	Prarit Bhargava <prarit@...hat.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lenny Szubowicz <lszubowi@...hat.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Robert Schöne <robert.schoene@...dresden.de>
Subject: Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to
 be held for duration of changing governors [v2]

On 5 August 2014 01:46, Saravana Kannan <skannan@...eaurora.org> wrote:
> The problem is when between one thread trying to cat a governor's file (say,
> sampling_rate) vs the governor getting a POLICY_EXIT.

I don't see two threads racing against each other here. Simply changing
the governor from conservative->ondemand creates this.

Or is it that the kernel is detecting two different orders of taking lock?

But during governor change, isn't the sysfs lock taken first as we are
storing a value to "scaling_governor"? So, isn't this a sysfs lock first
in all cases?

In short, I am still unclear about the *exact* problem here.

> Could you please look at my policy free/remove patches? If you can do that,
> I can work on a fix for this. It might also be simpler to fix after my patch
> series (not sure, might be).

I had an overall look of those on the day you posted them, but haven't
commented yet as was going away..

There is no way those can land in 3.17-rc1 atleast and so we still have
some time to get them pushed..

Anyway, they are my number two priority and the number one is this bug,
which we have to fix in stable kernels as well. So, a dependency on your
series wouldn't work..

Let me see if I can get some solution to this problem first.
--
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/