From patchwork Tue Feb 9 03:31:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 61480 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp1803920lbl; Mon, 8 Feb 2016 19:33:43 -0800 (PST) X-Received: by 10.98.68.220 with SMTP id m89mr47033413pfi.65.1454988823244; Mon, 08 Feb 2016 19:33:43 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e18si32056480pfj.30.2016.02.08.19.33.42; Mon, 08 Feb 2016 19:33:43 -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 S932507AbcBIDdk (ORCPT + 30 others); Mon, 8 Feb 2016 22:33:40 -0500 Received: from mail-pf0-f177.google.com ([209.85.192.177]:35135 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932313AbcBIDcp (ORCPT ); Mon, 8 Feb 2016 22:32:45 -0500 Received: by mail-pf0-f177.google.com with SMTP id c10so53519085pfc.2 for ; Mon, 08 Feb 2016 19:32:44 -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=KZX8KqC1oY3NOmkaw01ZMcG9BtOaptUXSqCkpV8+l8o=; b=X3vPdu/SChCBfst9MxnEbEY/+VHbDwJFZDTSdW2TljPdPgIGUMVgol9Xudm+kw5386 e0eSzy1ERlGlTxpvdwp1SN5SDba8qL1pzeWFqGWFX3VpXhk0ViGXKHHZGB7c9uGRSwJD MVFOxmTH3rnvIW4eZbaMa1SYjT/7EM87h4z/w= 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=KZX8KqC1oY3NOmkaw01ZMcG9BtOaptUXSqCkpV8+l8o=; b=VEBCezl2x+NMUBu/7j2xSUjgW/wx/ci93bdZYi/FHKMLCg9wnFuIqqWzYaCpqhmh2R QjdaJ3HZOW1sD4VgdVc0nxYt2ixGPWk/Upkd1D1uAlk/uTEHgAcDigTHN2gvsa2NxRwi WO0S8H3KR5J14zPJlZRpXm/kGgt9hpa/wN3r+TjR75TG4i/ALcpMwy1bO0Eius1GBg/g ++ob046sSpJaLeQ/P868GaomXExs8m/cpPsHT6P4aMGKwV/vwAcRzr9QAayDn/Rx/yn4 c1giycdkAqz0eMHtfJGwCMxkdn+1ycsogK/OxwPXiN+7uW1iSrMV5028TqsLU3Irxq2Y RTkw== X-Gm-Message-State: AG10YOQ/kBCnNWvLmuVjXe0tbM9R8cqW6PBlJTq9hczPiqxWFpLrj2AEw+t2MChqEZkzc00D X-Received: by 10.98.16.150 with SMTP id 22mr17550324pfq.128.1454988764461; Mon, 08 Feb 2016 19:32:44 -0800 (PST) Received: from localhost ([122.172.22.246]) by smtp.gmail.com with ESMTPSA id q14sm46379156pfq.81.2016.02.08.19.32.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2016 19:32:43 -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 V4 5/6] Revert "cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT" Date: Tue, 9 Feb 2016 09:01:35 +0530 Message-Id: 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") Signed-off-by: Viresh Kumar Reported-by: Juri Lelli Tested-by: Juri Lelli Tested-by: Shilpasri G Bhat --- 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;