From patchwork Fri Jan 4 11:42:49 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sudeep Holla X-Patchwork-Id: 154770 Delivered-To: patch@linaro.org Received: by 2002:a2e:299d:0:0:0:0:0 with SMTP id p29-v6csp528749ljp; Fri, 4 Jan 2019 03:42:59 -0800 (PST) X-Google-Smtp-Source: AFSGD/UeoiLI68oDEIAqFZtzYZRQjPGttCfXNWebvJi2vUNgoH3hnovH6X3DGgtIzRRFME66jwGv X-Received: by 2002:a62:3305:: with SMTP id z5mr52832951pfz.112.1546602179582; Fri, 04 Jan 2019 03:42:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546602179; cv=none; d=google.com; s=arc-20160816; b=0EujuVQ306e5lujQWxU5eU4lpmqoeBPnDqce+qiLtPQLdpZoVAexK95zmQSnHVTDkg a9Tp5hjcGuK8zfjh30VlkNBP0d+70IaiWmfcMQaxzCm3k8l9eTBt6BmxXuO/ABd1Wmlo BfZUC06ny9Q3ytwNVfxRXLtKFdt8a2ZK1P2ibddc18EoQgM1L9QE8nUxzYhFkEngOli1 vslH32bhuJYnzm2vk711CDMg7Jr7iqxH/numguQAOuC1P7JRVV74ruXBqG0Tyus4NACZ evsUdkLc47TFkrbIefKRqw8x6lRwEI8ks8YFpSd9cMIs/1vzacdPCsjK+hqggutOeikL xfxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=2lyD3ykfaeZe7wmav+4yah7NHM6JQay2aXnJMgxbRXU=; b=F71tp3jtlAhgA5YgGaUpATQ6Vuy6h/4rGQbrTYemSh9f+6FRYM8zoVAaoaI6CHXtzx 6bEPvoBKCEV6aB3+f5srWj/+LyzYvnaIB40z6cHcxX5aWgmatM/r9aPfVp/Nkj0ESHL6 Xlm4yJrdl+A+4ENMB/LJlEz0oaW7U1J/rYicLSWD3uvBhQFN4GrRo0lrQ3UXeN19tnwR CLvLFIqy+fRHu6b8CP2MVBMq85i3TIMLHQreFahAnkZozo1QBLjxUjXWAu6tIG6eH88c D4EYchei6S4O3Vtc96ESOttFU8fuoFo/JKeqykwrI7GTg+8uL+TPxAaz44terwb/kd/w ErNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y25si14950042pgl.226.2019.01.04.03.42.58; Fri, 04 Jan 2019 03:42:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727897AbfADLm6 (ORCPT + 11 others); Fri, 4 Jan 2019 06:42:58 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:40706 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726622AbfADLm6 (ORCPT ); Fri, 4 Jan 2019 06:42:58 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D02F315AD; Fri, 4 Jan 2019 03:42:57 -0800 (PST) Received: from usa.arm.com (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id E12713F5D4; Fri, 4 Jan 2019 03:42:56 -0800 (PST) From: Sudeep Holla To: linux-pm@vger.kernel.org Cc: Sudeep Holla , "Rafael J. Wysocki" , Viresh Kumar Subject: [PATCH] cpufreq: check if policy is inactive before calling __cpufreq_get Date: Fri, 4 Jan 2019 11:42:49 +0000 Message-Id: <20190104114249.5355-1-sudeep.holla@arm.com> X-Mailer: git-send-email 2.17.1 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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. 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 ]--- Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Signed-off-by: Sudeep Holla --- drivers/cpufreq/cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Hi Viresh, Rafael, I don't know the reason why we call __cpufreq_get here instead of cpufreq_get which checks if the policy is active or not. I bumped into this when I was testing Viresh's OPP fix. This patch can be improved to avoid policy to cpu, back to policy reference in the path, but I wanted to get the information I might be missing. Regards, Sudeep -- 2.17.1 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 6f23ebb395f1..cfc502385855 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -712,7 +712,7 @@ store_one(scaling_max_freq, max); static ssize_t show_cpuinfo_cur_freq(struct cpufreq_policy *policy, char *buf) { - unsigned int cur_freq = __cpufreq_get(policy); + unsigned int cur_freq = cpufreq_get(policy->cpu); if (cur_freq) return sprintf(buf, "%u\n", cur_freq);