[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKohpom-UFkvORuuzAEUj1jVofHTEkDMhSmMUo4_0Xxfj605-g@mail.gmail.com>
Date: Tue, 10 Sep 2013 12:22:12 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Stephen Boyd <sboyd@...eaurora.org>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
Patch Tracking <patches@...aro.org>,
"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] cpufreq: serialize calls to __cpufreq_governor()
Back finally and I see lots of mails over cpufreq stuff.. :)
On 3 September 2013 18:50, Srivatsa S. Bhat
<srivatsa.bhat@...ux.vnet.ibm.com> wrote:
> This doesn't solve the problem completely: it prevents the store_*() task
> from continuing *only* when it concurrently executes the __cpufreq_governor()
> function along with the CPU offline task. But if the two calls don't overlap,
> we will still have the possibility where the store_*() task tries to acquire
> the timer mutex after the CPU offline task has just finished destroying it.
How exactly? My brain is still on vacations :)
Anyway, this was one of the problem that I tried to solve with my patch.
But there can be other race conditions where things can go wrong and so
that patch may still be useful.
Call to __cpufreq_governor() must be serialized I believe.
--
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