public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Sasha Levin <sashal@kernel.org>,
	linux-pm@vger.kernel.org
Subject: [PATCH AUTOSEL 4.14 03/16] cpufreq: check if policy is inactive early in __cpufreq_get()
Date: Sat,  9 Feb 2019 13:49:14 -0500	[thread overview]
Message-ID: <20190209184927.126791-3-sashal@kernel.org> (raw)
In-Reply-To: <20190209184927.126791-1-sashal@kernel.org>

From: Sudeep Holla <sudeep.holla@arm.com>

[ Upstream commit 2f66196208c98b3d1b4294edffb2c5a8197be899 ]

cpuinfo_cur_freq gets current CPU frequency as detected by hardware
while scaling_cur_freq last known CPU frequency. Some platforms may not
allow checking the CPU frequency of an offline CPU or the associated
resources may have been released via cpufreq_exit when the CPU gets
offlined, in which case the policy would have been invalidated already.
If we attempt to get current frequency from the hardware, it may result
in hang or crash.

For example on Juno, I see:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000188
[0000000000000188] pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 5 PID: 4202 Comm: cat Not tainted 4.20.0-08251-ga0f2c0318a15-dirty #87
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform
pstate: 40000005 (nZcv daif -PAN -UAO)
pc : scmi_cpufreq_get_rate+0x34/0xb0
lr : scmi_cpufreq_get_rate+0x34/0xb0
Call trace:
 scmi_cpufreq_get_rate+0x34/0xb0
 __cpufreq_get+0x34/0xc0
 show_cpuinfo_cur_freq+0x24/0x78
 show+0x40/0x60
 sysfs_kf_seq_show+0xc0/0x148
 kernfs_seq_show+0x44/0x50
 seq_read+0xd4/0x480
 kernfs_fop_read+0x15c/0x208
 __vfs_read+0x60/0x188
 vfs_read+0x94/0x150
 ksys_read+0x6c/0xd8
 __arm64_sys_read+0x24/0x30
 el0_svc_common+0x78/0x100
 el0_svc_handler+0x38/0x78
 el0_svc+0x8/0xc
---[ end trace 3d1024e58f77f6b2 ]---

So fix the issue by checking if the policy is invalid early in
__cpufreq_get before attempting to get the current frequency.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/cpufreq/cpufreq.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 93754300cb57..66c2790dcc5f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1523,17 +1523,16 @@ static unsigned int __cpufreq_get(struct cpufreq_policy *policy)
 {
 	unsigned int ret_freq = 0;
 
-	if (!cpufreq_driver->get)
+	if (unlikely(policy_is_inactive(policy)) || !cpufreq_driver->get)
 		return ret_freq;
 
 	ret_freq = cpufreq_driver->get(policy->cpu);
 
 	/*
-	 * Updating inactive policies is invalid, so avoid doing that.  Also
-	 * if fast frequency switching is used with the given policy, the check
+	 * If fast frequency switching is used with the given policy, the check
 	 * against policy->cur is pointless, so skip it in that case too.
 	 */
-	if (unlikely(policy_is_inactive(policy)) || policy->fast_switch_enabled)
+	if (policy->fast_switch_enabled)
 		return ret_freq;
 
 	if (ret_freq && policy->cur &&
@@ -1562,10 +1561,7 @@ unsigned int cpufreq_get(unsigned int cpu)
 
 	if (policy) {
 		down_read(&policy->rwsem);
-
-		if (!policy_is_inactive(policy))
-			ret_freq = __cpufreq_get(policy);
-
+		ret_freq = __cpufreq_get(policy);
 		up_read(&policy->rwsem);
 
 		cpufreq_cpu_put(policy);
-- 
2.19.1


  parent reply	other threads:[~2019-02-09 18:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09 18:49 [PATCH AUTOSEL 4.14 01/16] ACPI: NUMA: Use correct type for printing addresses on i386-PAE Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 02/16] perf test shell: Use a fallback to get the pathname in vfs_getname Sasha Levin
2019-02-09 18:49 ` Sasha Levin [this message]
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 04/16] drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 05/16] drm/bridge: tc358767: fix single lane configuration Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 06/16] drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 07/16] drm/bridge: tc358767: reject modes which require too much BW Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 08/16] drm/bridge: tc358767: fix output H/V syncs Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 09/16] nvme-pci: use the same attributes when freeing host_mem_desc_bufs Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 10/16] ARM: dts: da850-evm: Correct the sound card name Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 11/16] ARM: dts: da850-lcdk: " Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 12/16] ARM: dts: kirkwood: Fix polarity of GPIO fan lines Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 13/16] gpio: pl061: handle failed allocations Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 14/16] drm/nouveau: Don't disable polling in fallback mode Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 15/16] drm/nouveau/falcon: avoid touching registers if engine is off Sasha Levin
2019-02-09 18:49 ` [PATCH AUTOSEL 4.14 16/16] cifs: Limit memory used by lock request calls to a page Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190209184927.126791-3-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox