From patchwork Mon Feb 8 11:39:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 61399 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp1384842lbl; Mon, 8 Feb 2016 03:43:17 -0800 (PST) X-Received: by 10.66.218.225 with SMTP id pj1mr40610200pac.40.1454931796979; Mon, 08 Feb 2016 03:43:16 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z7si46062403par.88.2016.02.08.03.43.16; Mon, 08 Feb 2016 03:43:16 -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; dkim=pass header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752982AbcBHLnO (ORCPT + 30 others); Mon, 8 Feb 2016 06:43:14 -0500 Received: from mail-pa0-f51.google.com ([209.85.220.51]:34430 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752191AbcBHLk2 (ORCPT ); Mon, 8 Feb 2016 06:40:28 -0500 Received: by mail-pa0-f51.google.com with SMTP id uo6so73847506pac.1 for ; Mon, 08 Feb 2016 03:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=FoH8iA2UhwOEjrKeTLiGTdFEhlbo6xXugLMra0Y+KvE=; b=HgdGQyvrxoCt4bb8R21YgwC72i9DbdFZdCXgx0puOuRemjDPhLT4imhi0YXt5ZDhh6 O5n91e7wAQ6djH/TntMWFOgRHvxxotC9ZQqLeuxGlzneDrkVvDUAjNpRtINbqFD0n/XN ysYPjzoYN3cpywWMYS3RTS+kY0jmZZlZqi4rU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=FoH8iA2UhwOEjrKeTLiGTdFEhlbo6xXugLMra0Y+KvE=; b=jlzzegHJD/Vrc+lz3BBEn2VqKxQvAQP29PFAEuYqz7DppAtHUfw+fsseEqRL4jwcsK rS36Z1xCw/MVOfJBeHrS6Dsx/pUhp0mwd9WhyqEkXevfyh1iLnST2akwsu7RgMoPTswL AMPxipAdrS23QKVBFEKiSQRtgncAAHhY0rcV4JQE2zhkU5U33enzPGdKzvQIP8lPLE7G UBr48EsFd853dsd3zcK0CQvD2VdtnWPMcqa2kPWwyfxtDvxVTX4rttIgdfW6kzA4V/hV Rvvh/QN1h9rtkasbz1QVLMRWNYMSuAD1JAo7/wlwfc0rl2COmTXg8jZ3PvoCZop8tajV rJZw== X-Gm-Message-State: AG10YORRLVbPTQd4U1iVgi6Ca+KPYSGYPiQi5InB4FvzJ6ECsSu8A8nR3OO2MWM5FHlg31Rl X-Received: by 10.67.7.129 with SMTP id dc1mr26464701pad.87.1454931628362; Mon, 08 Feb 2016 03:40:28 -0800 (PST) Received: from localhost ([122.172.22.246]) by smtp.gmail.com with ESMTPSA id r5sm42978436pap.7.2016.02.08.03.40.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2016 03:40:27 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , juri.lelli@arm.com Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, skannan@codeaurora.org, peterz@infradead.org, mturquette@baylibre.com, steve.muckle@linaro.org, vincent.guittot@linaro.org, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, shilpa.bhat@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, Viresh Kumar Subject: [PATCH V3 05/13] Revert "cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT" Date: Mon, 8 Feb 2016 17:09:19 +0530 Message-Id: <7e22fb3b804f65b33a37c871a6d5023897b8641f.1454931188.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.7.1.370.gb2aa7f8 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Earlier, when the struct freq-attr was used to represent governor attributes, the standard cpufreq show/store sysfs attribute callbacks were applied to the governor tunable attributes and they always acquire the policy->rwsem lock before carrying out the operation. That could have resulted in an ABBA deadlock if governor tunable attributes are removed under policy->rwsem while one of them is being accessed concurrently (if sysfs attributes removal wins the race, it will wait for the access to complete with policy->rwsem held while the attribute callback will block on policy->rwsem indefinitely). We attempted to address this issue by dropping policy->rwsem around governor tunable attributes removal (that is, around invocations of the ->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT) in cpufreq_set_policy(), but that opened up race conditions that had not been possible with policy->rwsem held all the time. The previous commit, "cpufreq: governor: New sysfs show/store callbacks for governor tunables", fixed the original ABBA deadlock by adding new governor specific show/store callbacks. We don't have to drop rwsem around invocations of governor event CPUFREQ_GOV_POLICY_EXIT anymore, and original fix can be reverted now. Fixes: 955ef4833574 ("cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT") Reported-by: Juri Lelli Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 5 ----- include/linux/cpufreq.h | 4 ---- 2 files changed, 9 deletions(-) -- 2.7.1.370.gb2aa7f8 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 29755fcbf200..9c62bf35b9dc 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -2204,10 +2204,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy, return ret; } - up_write(&policy->rwsem); ret = __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT); - down_write(&policy->rwsem); - if (ret) { pr_err("%s: Failed to Exit Governor: %s (%d)\n", __func__, old_gov->name, ret); @@ -2223,9 +2220,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy, if (!ret) goto out; - up_write(&policy->rwsem); __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT); - down_write(&policy->rwsem); } /* new governor failed, so re-start old one */ diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 11aa93134493..2a029c587975 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -100,10 +100,6 @@ struct cpufreq_policy { * - Any routine that will write to the policy structure and/or may take away * the policy altogether (eg. CPU hotplug), will hold this lock in write * mode before doing so. - * - * Additional rules: - * - Lock should not be held across - * __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT); */ struct rw_semaphore rwsem;