From patchwork Thu Jun 27 04:56:27 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 18140 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ve0-f200.google.com (mail-ve0-f200.google.com [209.85.128.200]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id C4D772390D for ; Thu, 27 Jun 2013 04:56:30 +0000 (UTC) Received: by mail-ve0-f200.google.com with SMTP id m1sf514688ves.11 for ; Wed, 26 Jun 2013 21:56:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:x-forwarded-to:x-forwarded-for:delivered-to :mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-google-group-id:list-post:list-help:list-archive:list-unsubscribe :content-type; bh=gRwPMt7jp0YjOEKAmlVdf9GdakDiajXCNKPHpx6wVO0=; b=gJfBjlf/ZOhfDwKWLk1wgIs/Hp4DjWpkxUZ5j1mj2Vo+dekR7BFHFfHyHUxQCWNLRJ 03MmbbOKLwPQVDtNypzS/813jsoNG5Zk0horD4d2+Ct6MxllGR6qIzBNjchhYCvu/zPK NbACfnF6s3y1E/iOztBgjyb4biqz5C4CMRtuMagk2x+Nzm3+2VXIq85PDF+4DpK5CKvJ ZrlInajQLeOBv+e+8Gl5XaNqXn8rnTzFHncOUwdQuMhHLieF40VIO6oX5vQa9J1rPxlF INn4BVGhDh6HHAV0AianyIrPzrccimezwmCsj/2H3TX94KxR0+KaxmedxGEgB6l3Qkd7 TLmQ== X-Received: by 10.224.129.196 with SMTP id p4mr7104187qas.6.1372308989811; Wed, 26 Jun 2013 21:56:29 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.49.48.115 with SMTP id k19ls701615qen.5.gmail; Wed, 26 Jun 2013 21:56:29 -0700 (PDT) X-Received: by 10.58.255.199 with SMTP id as7mr2978564ved.23.1372308989574; Wed, 26 Jun 2013 21:56:29 -0700 (PDT) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by mx.google.com with ESMTPS id fo4si358973vec.60.2013.06.26.21.56.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 21:56:29 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.212.47 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.212.47; Received: by mail-vb0-f47.google.com with SMTP id x14so238401vbb.20 for ; Wed, 26 Jun 2013 21:56:29 -0700 (PDT) X-Received: by 10.220.70.140 with SMTP id d12mr2942081vcj.15.1372308989446; Wed, 26 Jun 2013 21:56:29 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.58.165.8 with SMTP id yu8csp134268veb; Wed, 26 Jun 2013 21:56:28 -0700 (PDT) X-Received: by 10.60.84.147 with SMTP id z19mr2087417oey.21.1372308987961; Wed, 26 Jun 2013 21:56:27 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mx.google.com with ESMTPS id ko2si173030oeb.7.2013.06.26.21.56.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 21:56:27 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.219.44 is neither permitted nor denied by best guess record for domain of viresh.kumar@linaro.org) client-ip=209.85.219.44; Received: by mail-oa0-f44.google.com with SMTP id l10so315974oag.3 for ; Wed, 26 Jun 2013 21:56:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.133.44 with SMTP id oz12mr2032660oeb.62.1372308987524; Wed, 26 Jun 2013 21:56:27 -0700 (PDT) Received: by 10.182.155.39 with HTTP; Wed, 26 Jun 2013 21:56:27 -0700 (PDT) In-Reply-To: <2081161.dnl1xTqcUT@vostro.rjw.lan> References: <2165396.dF1lQyPRVT@vostro.rjw.lan> <2081161.dnl1xTqcUT@vostro.rjw.lan> Date: Thu, 27 Jun 2013 10:26:27 +0530 Message-ID: Subject: Re: [PATCH 13/13] cpufreq: make sure frequency transitions are serialized From: Viresh Kumar To: "Rafael J. Wysocki" Cc: linaro-kernel@lists.linaro.org, patches@linaro.org, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, robin.randhawa@arm.com, Steve.Bannister@arm.com, Liviu.Dudau@arm.com, charles.garcia-tobin@arm.com, arvind.chauhan@arm.com, dave.martin@arm.com X-Gm-Message-State: ALoCoQkM2dgWPh2Ema7Jefu19qnk1ru9naW2YDSlAMSpoYF0oSRuq74QEhX6Fms8owR9y96NCjL7 X-Original-Sender: viresh.kumar@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.212.47 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On 27 June 2013 03:27, Rafael J. Wysocki wrote: > Well, now, seeing that the locking around this seems to be kind of haphazard, > I'm wondering what prevents two different threads from doing CPUFREQ_PRECHANGE > concurrently in such a way that thread A will check transition_ongoing > and thread B will check transition_ongoing and then both will set it if it > was 'false' before. And then one of them will trigger the WARN() in > CPUFREQ_POSTCHANGE. > > Is there any protection in place and if so then how does it work? cpufreq_notify_transition() is called from driver->target() which is called from __cpufreq_driver_target(). __cpufreq_driver_target() is called directly by governors and cpufreq_driver_target() otherwise. cpufreq_driver_target() implements proper locking and so it is fine. __cpufreq_driver_target() is called from governors. From governors it is is serialized in the sense two threads wouldn't call it at the same time. And so I thought this will work. But I just found a mistake in my code. For multi-socket platforms with clock domains for sockets/clusters, a single instance of transition_ongoing isn't enough and so this must be embedded in struct cpufreq_policy. Below patch must get this fixed (Attached). -------------x---------------------x----------------- From: Viresh Kumar Date: Wed, 19 Jun 2013 10:16:55 +0530 Subject: [PATCH] cpufreq: make sure frequency transitions are serialized Whenever we are changing frequency of a cpu, we are calling PRECHANGE and POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE shouldn't be called twice contiguously. This can happen due to bugs in users of __cpufreq_driver_target() or actual cpufreq drivers who are sending these notifiers. This patch adds some protection against this. Now, we keep track of the last transaction and see if something went wrong. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 14 ++++++++++++++ include/linux/cpufreq.h | 1 + 2 files changed, 15 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 2d53f47..75715f1 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -264,6 +264,12 @@ void __cpufreq_notify_transition(struct cpufreq_policy *policy, switch (state) { case CPUFREQ_PRECHANGE: + if (WARN(policy->transition_ongoing, + "In middle of another frequency transition\n")) + return; + + policy->transition_ongoing = true; + /* detect if the driver reported a value as "old frequency" * which is not equal to what the cpufreq core thinks is * "old frequency". @@ -283,6 +289,12 @@ void __cpufreq_notify_transition(struct cpufreq_policy *policy, break; case CPUFREQ_POSTCHANGE: + if (WARN(!policy->transition_ongoing, + "No frequency transition in progress\n")) + return; + + policy->transition_ongoing = false; + adjust_jiffies(CPUFREQ_POSTCHANGE, freqs); pr_debug("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new, (unsigned long)freqs->cpu); @@ -1458,6 +1470,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy, if (cpufreq_disabled()) return -ENODEV; + if (policy->transition_ongoing) + return -EBUSY; /* Make sure that target_freq is within supported range */ if (target_freq > policy->max) diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 037d36a..8c13a45 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -115,6 +115,7 @@ struct cpufreq_policy { struct kobject kobj; struct completion kobj_unregister; + bool transition_ongoing; /* Tracks transition status */ }; #define CPUFREQ_ADJUST (0)