Received: by 10.223.176.46 with SMTP id f43csp4738591wra; Tue, 23 Jan 2018 13:59:24 -0800 (PST) X-Google-Smtp-Source: AH8x227fF3fJ7DzkAvm5VFx+NdqZAFNMwtlGYM1ZvqDJcLhwtC41S/urcRENuQpLOUBDcME62po/ X-Received: by 10.107.81.20 with SMTP id f20mr5976447iob.174.1516744764841; Tue, 23 Jan 2018 13:59:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516744764; cv=none; d=google.com; s=arc-20160816; b=OslRUN1QQBYQU+/7prBjA9I+V9Mxf4uBHVzMq5FIxci+DZ13lnUlyXEzfEren8kNRX 3ycmYFskdW5eYVoWlas5YFv6RsnNEP8dDNkNydOPJMf3VE0iFGO4rgbJd3dgzhmwa9IS oRTlUJnZD+9D7GbiaBksqijNSqUdlzSmwF6R/89qWLJKbBOhwCeYRQkplqVAwnfl/6iq xlRYPHuk3T8RQP2fKwrhCatGv/6DIv1KcQquaXnHrSdz2vjBlbUNZlJxYSC4/hEyzdOq stdbn4uQzrJ2G4N/1js7rkcL388vsPOoHaEGXqwWXALk0ySCuuq3KX/FuRN5S1Sn4gJi DgcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=QAXINgwWkx3rfyBfDD0fh730PgXiF2Osj2WjDh03QQ8=; b=jHuSfwvyjjD5fPH5CE8+Nhh/kWYt5vsuqBKUHevyWbRutsZ0ZV0kF2DsnbcwALbnLj svNQEZ9YkQHnvgI841PmaPXVmMpFWgeCazdIv56Tqlqze3KsVjAkGKPr+gpnnR8sNeoQ iZUMfzMU4y5cie70jGtlGNAa68A5+ZwtytMARfKy4URu5eQReE4gK2Lp5ViLcee+HEV7 lie8hW17DNFTgfiwmaitcfaln95k4j1lAC/lH4WUS9FTEJoY5/pTFZBLn0EYHBAmDq8+ eiXB8KeH3eaVxdS5BLB+KAwuse70mnpyUAkZEtZzvUBwyEmIzigKCY0c194JOTaYoouT wUlA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u185si13972934ioe.331.2018.01.23.13.59.07; Tue, 23 Jan 2018 13:59:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932220AbeAWV6f (ORCPT + 99 others); Tue, 23 Jan 2018 16:58:35 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:16981 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932071AbeAWV6e (ORCPT ); Tue, 23 Jan 2018 16:58:34 -0500 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com id ; Tue, 23 Jan 2018 13:58:18 -0800 Received: from HQMAIL103.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Tue, 23 Jan 2018 13:58:34 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 23 Jan 2018 13:58:34 -0800 Received: from HQMAIL105.nvidia.com (172.20.187.12) by HQMAIL103.nvidia.com (172.20.187.11) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 23 Jan 2018 21:58:33 +0000 Received: from byan-linux.NVIDIA.COM (10.124.1.5) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 23 Jan 2018 21:58:33 +0000 From: Bo Yan To: , , CC: , , Bo Yan Subject: [PATCH] cpufreq: skip cpufreq resume if it's not suspended Date: Tue, 23 Jan 2018 13:57:55 -0800 Message-ID: <1516744675-21233-1-git-send-email-byan@nvidia.com> X-Mailer: git-send-email 2.7.4 X-NVConfidentiality: public MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org cpufreq_resume can be called even without preceding cpufreq_suspend. This can happen in following scenario: suspend_devices_and_enter --> dpm_suspend_start --> dpm_prepare --> device_prepare : this function errors out --> dpm_suspend: this is skipped due to dpm_prepare failure this means cpufreq_suspend is skipped over --> goto Recover_platform, due to previous error --> goto Resume_devices --> dpm_resume_end --> dpm_resume --> cpufreq_resume In case schedutil is used as frequency governor, cpufreq_resume will eventually call sugov_start, which does following: memset(sg_cpu, 0, sizeof(*sg_cpu)); .... This effectively erases function pointer for frequency update, causing crash later on. The function pointer would have been set correctly if subsequent cpufreq_add_update_util_hook runs successfully, but that function returns earlier because cpufreq_suspend was not called: if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu))) return; Ideally, suspend should succeed, then things will be fine. But even in case of suspend failure, system should not crash. The fix is to check cpufreq_suspended first, if it's false, that means cpufreq_suspend was not called in the first place, so do not resume cpufreq. Signed-off-by: Bo Yan --- drivers/cpufreq/cpufreq.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 41d148af7748..95b1c4afe14e 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1680,6 +1680,10 @@ void cpufreq_resume(void) if (!cpufreq_driver) return; + if (unlikely(!cpufreq_suspended)) { + pr_warn("%s: resume after failing suspend\n", __func__); + return; + } cpufreq_suspended = false; if (!has_target() && !cpufreq_driver->resume) -- 2.7.4