From patchwork Wed Feb 3 14:02:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 61093 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp310312lbl; Wed, 3 Feb 2016 06:02:54 -0800 (PST) X-Received: by 10.66.141.229 with SMTP id rr5mr2321806pab.123.1454508172829; Wed, 03 Feb 2016 06:02:52 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h26si9536514pfh.169.2016.02.03.06.02.52; Wed, 03 Feb 2016 06:02:52 -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 S1755917AbcBCOCs (ORCPT + 30 others); Wed, 3 Feb 2016 09:02:48 -0500 Received: from mail-pf0-f181.google.com ([209.85.192.181]:35203 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932711AbcBCOCn (ORCPT ); Wed, 3 Feb 2016 09:02:43 -0500 Received: by mail-pf0-f181.google.com with SMTP id 65so14453922pfd.2 for ; Wed, 03 Feb 2016 06:02:42 -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=h3m6hY4r/7zylkGolXiuRilxEzFiVe3hx7iKmsTogLI=; b=WG4ttO95ZITaSrB37Epsgj5vsa0HVfNpKC2lE0d+WMuZm2bBPyY3ecrdXIC7yCd8h4 kVoVA7E2f+boZnZBSvc0onwcyBba5OzXGzAS1+DZqkRedH3Lw8NoV9HX2i8z4FJagG33 tYVjJp2ofMPRl1q/8bhIqJULL+hN/vyQce3+I= 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=h3m6hY4r/7zylkGolXiuRilxEzFiVe3hx7iKmsTogLI=; b=Gp/ckSHnXMWrINQkD1B5zKg276ZMFMmU4i8FXzBHz/Q8a6M6cuxhvKn5q/NfdIJKDk KrJjElxlWtdDzOQt16gBdLVzsdiwWZrYwDgQQnYiVhDSxM6Dy0HxOr5luyyYWowW7opj UgO7lkTjhlFRDxLLBNLl+F3Sf+estGZw6bwIZgoVNIbuVrsUpRIbcqa7HaHunPtm/mYR AjYp/brB6CHpDQWi9qB2xT71D9Xx6uBqgrsHZUrTW+TNyLAU2w8k0nxKctPwGTgQHxgj DbX8tQoQRP4eRtOLXx7I7YBkOrZ9MhXE2f+FnRuFQbjymEVyrJyM4iuIp/q46sXkBR5w f9sA== X-Gm-Message-State: AG10YOQxFHc6u45m+mx4iPs6rYU3zPsJTcYLr3Im6Dbpw1XBdbEqmLR3fbbRsDzrnCGm/gqL X-Received: by 10.98.67.67 with SMTP id q64mr2359686pfa.133.1454508162696; Wed, 03 Feb 2016 06:02:42 -0800 (PST) Received: from localhost ([122.172.22.246]) by smtp.gmail.com with ESMTPSA id l14sm10197516pfb.73.2016.02.03.06.02.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2016 06:02:42 -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, linux-kernel@vger.kernel.org, Viresh Kumar Subject: [PATCH V2 4/7] Revert "cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT" Date: Wed, 3 Feb 2016 19:32:20 +0530 Message-Id: X-Mailer: git-send-email 2.7.0.79.gdc08a19 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.0.79.gdc08a19 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index e979ec78b695..5f7e24567e0e 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -2155,10 +2155,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); @@ -2174,9 +2171,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 88a4215125bc..79b87cebaa9c 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;