Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]
From: Saravana Kannan
Date: Wed Jul 30 2014 - 22:07:15 EST
On 07/30/2014 07:16 PM, Rafael J. Wysocki wrote:
On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote:
[cut]
This patch effectively reverts commit 955ef483.
The issue reported in this patch is valid. We are seeing that internally
too. I believe I reported it in another thread (within the past month).
However, the original patch fixes a real deadlock issue (I'm too tired
to look it up now). We can revet the original, but it's going to bring
back the original issue. I just want to make sure Prarit and Raphael
realize this before proceeding.
I do have plans for a proper fix for the mainline (not stable branches),
but plan to do that after the current set of suspend/hotplug patches go
through. The fix would be easier to make after that.
OK, I'm convinced by this.
I suppose we should push it for -stable from 3.10 through 3.15.x, right?
Rafael, I think that is a good idea. I'm not sure what the protocol is for
adding stable@xxxxxxxxxx though ...
I'll take care of this, thanks!
But you aren't going to pull the in for the next release, right?
What do you mean?
Reverting the commit will bring back another dead lock issue. So, you
don't want to revert it on mainline. Do I still not make sense because
I'm not using the right terms?
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/