From patchwork Thu Jul 6 17:53:20 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vikram Mulukutla X-Patchwork-Id: 9828693 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 65570602CA for ; Thu, 6 Jul 2017 17:54:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 57D6B285E1 for ; Thu, 6 Jul 2017 17:54:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4BDFA28650; Thu, 6 Jul 2017 17:54:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B845D285E1 for ; Thu, 6 Jul 2017 17:54:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751813AbdGFRyr (ORCPT ); Thu, 6 Jul 2017 13:54:47 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60046 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751765AbdGFRyq (ORCPT ); Thu, 6 Jul 2017 13:54:46 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id DFFE06084D; Thu, 6 Jul 2017 17:54:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1499363685; bh=qP5Ro1e8PqGK2NBzmeBgFYivwOj9bUCRM60GIMEuUWk=; h=From:To:Cc:Subject:Date:From; b=YTiVB4bL9mTlrRQch4Gol+7r0Jn4bROXXuVeZJKhpq41caFcbbMl/TjGKfERGBgkY KM1/yDMS5m7DL2bKriNzGq80m48/K1S5c4DrWVbfw7yFljar42UriPDahYAsygCxeG RS3DCLFB7AL4WunS2r7w/ZiZRmH5qYU8/zKgVjAQ= Received: from kernel-hog-04.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: markivx@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5BF946081B; Thu, 6 Jul 2017 17:54:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1499363685; bh=qP5Ro1e8PqGK2NBzmeBgFYivwOj9bUCRM60GIMEuUWk=; h=From:To:Cc:Subject:Date:From; b=YTiVB4bL9mTlrRQch4Gol+7r0Jn4bROXXuVeZJKhpq41caFcbbMl/TjGKfERGBgkY KM1/yDMS5m7DL2bKriNzGq80m48/K1S5c4DrWVbfw7yFljar42UriPDahYAsygCxeG RS3DCLFB7AL4WunS2r7w/ZiZRmH5qYU8/zKgVjAQ= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5BF946081B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=markivx@codeaurora.org From: Vikram Mulukutla To: rafael.j.wysocki@intel.com, viresh.kumar@linaro.org Cc: juri.lelli@arm.com, skannan@codeaurora.org, linux-pm@vger.kernel.org, Vikram Mulukutla Subject: [PATCH] cpufreq: schedutil: Fix sugov_start versus sugov_update_shared race Date: Thu, 6 Jul 2017 10:53:20 -0700 Message-Id: <1499363600-10732-1-git-send-email-markivx@codeaurora.org> X-Mailer: git-send-email 1.9.1 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP With a shared policy in place, when one of the CPUs in the policy is hotplugged out and then brought back online, sugov_stop and sugov_start are called in order. sugov_stop removes utilization hooks for each CPU in the policy and does nothing else in the for_each_cpu loop. sugov_start on the other hand iterates through the CPUs in the policy and re-initializes the per-cpu structure _and_ adds the utilization hook. This implies that the scheduler is allowed to invoke a CPU's utilization update hook when the rest of the per-cpu structures have yet to be re-inited. Apart from some strange values in tracepoints this doesn't cause a problem, but if we do end up accessing a pointer from the per-cpu sugov_cpu structure somewhere in the sugov_update_shared path, we will likely see crashes since the memset for another CPU in the policy is free to race with sugov_update_shared from the CPU that is ready to go. So let's fix this now to first init all per-cpu structures, and then add the per-cpu utilization update hooks all at once. Signed-off-by: Vikram Mulukutla Acked-by: Viresh Kumar --- kernel/sched/cpufreq_schedutil.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 076a2e3..29a3970 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -610,6 +610,11 @@ static int sugov_start(struct cpufreq_policy *policy) sg_cpu->sg_policy = sg_policy; sg_cpu->flags = SCHED_CPUFREQ_RT; sg_cpu->iowait_boost_max = policy->cpuinfo.max_freq; + } + + for_each_cpu(cpu, policy->cpus) { + struct sugov_cpu *sg_cpu = &per_cpu(sugov_cpu, cpu); + cpufreq_add_update_util_hook(cpu, &sg_cpu->update_util, policy_is_shared(policy) ? sugov_update_shared :