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]
Message-ID: <CAKohpo=VJJFxKo5hNH3GNOZpjeHBc9fWORD9h7SThaFtkM__FA@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ