From patchwork Wed Aug 12 08:12:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 52325 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-la0-f71.google.com (mail-la0-f71.google.com [209.85.215.71]) by patches.linaro.org (Postfix) with ESMTPS id 761F9218E7 for ; Wed, 12 Aug 2015 08:13:14 +0000 (UTC) Received: by labth1 with SMTP id th1sf3241242lab.2 for ; Wed, 12 Aug 2015 01:13:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe; bh=jQ3shJSeRjZpNRhH3isvI4PzVX+QMvTun9tbcp0E/Aw=; b=RxHigHY6ndaolEUl0PFKpywD5rNhdXQaAzkYykGkX69tFdrW6cFLccMvUE7olSIlL/ bHLXO8cBEP+qBEoGPEvQr3fajBZ/RV3vifGYGj4XnAyHqiQ9JTbBsCT54eoPUmHbvP/M jk/6yRjfX6TK0NAU8q+dYQrTe+4g3fpvAYH1KB/NKV2imiP5TyZDJ8oXbT3CU0Bv8xb4 e+ScRBkfeObgMfGr2UzI0rt7VT3RGeAy2BhpjWah4fU2iGpFWrS+NL6qOrVhOwIZlhSW L5QeeFaC8Kz8a3cZWKqmivDasROdoaosA60OQXrMx9OaXD/2ShQrHhTa2wlp7DE5GcUC FcVg== X-Gm-Message-State: ALoCoQlUSbu/XWJBtkxQJWbP0q+W8G9gsv8HQ0WGEgHITZ4Itsm/9i2m5ZsQBv3J/txyNz6rbNhw X-Received: by 10.152.1.164 with SMTP id 4mr3192063lan.2.1439367193099; Wed, 12 Aug 2015 01:13:13 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.242.2 with SMTP id wm2ls11916lac.38.gmail; Wed, 12 Aug 2015 01:13:12 -0700 (PDT) X-Received: by 10.112.55.105 with SMTP id r9mr30775627lbp.89.1439367192822; Wed, 12 Aug 2015 01:13:12 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com. [209.85.215.52]) by mx.google.com with ESMTPS id wq7si3575713lbc.105.2015.08.12.01.13.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2015 01:13:12 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.52 as permitted sender) client-ip=209.85.215.52; Received: by lahi9 with SMTP id i9so4918134lah.2 for ; Wed, 12 Aug 2015 01:13:12 -0700 (PDT) X-Received: by 10.112.160.42 with SMTP id xh10mr30948505lbb.88.1439367192197; Wed, 12 Aug 2015 01:13:12 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.7.198 with SMTP id l6csp162372lba; Wed, 12 Aug 2015 01:13:10 -0700 (PDT) X-Received: by 10.69.11.5 with SMTP id ee5mr65336722pbd.89.1439367190124; Wed, 12 Aug 2015 01:13:10 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bw14si8232905pdb.116.2015.08.12.01.13.09; Wed, 12 Aug 2015 01:13:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754262AbbHLINI (ORCPT + 12 others); Wed, 12 Aug 2015 04:13:08 -0400 Received: from mail-pa0-f53.google.com ([209.85.220.53]:35795 "EHLO mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754252AbbHLINC (ORCPT ); Wed, 12 Aug 2015 04:13:02 -0400 Received: by pacgr6 with SMTP id gr6so9534356pac.2 for ; Wed, 12 Aug 2015 01:13:01 -0700 (PDT) X-Received: by 10.68.218.104 with SMTP id pf8mr65147330pbc.31.1439367181491; Wed, 12 Aug 2015 01:13:01 -0700 (PDT) Received: from localhost ([122.171.186.190]) by smtp.gmail.com with ESMTPSA id m4sm5384439pda.90.2015.08.12.01.13.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 12 Aug 2015 01:13:00 -0700 (PDT) Date: Wed, 12 Aug 2015 13:42:57 +0530 From: Viresh Kumar To: Russell King - ARM Linux Cc: "Rafael J. Wysocki" , Eduardo Valentin , Yadwinder Singh Brar , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" Subject: Re: 3.18: lockdep problems in cpufreq Message-ID: <20150812081257.GC16445@linux> References: <20141214213655.GA11285@n2100.arm.linux.org.uk> <20150518185645.GA28053@n2100.arm.linux.org.uk> <2574268.XBqpdL2VLI@vostro.rjw.lan> <20150811170357.GA24529@n2100.arm.linux.org.uk> <20150812051659.GI32049@linux> <20150812072129.GD7557@n2100.arm.linux.org.uk> <20150812073530.GA16445@linux> <20150812074925.GG7557@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150812074925.GG7557@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pm-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: viresh.kumar@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.52 as permitted sender) smtp.mailfrom=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On 12-08-15, 08:49, Russell King - ARM Linux wrote: > The problem will be back-porting it to stable kernels, because I think > it's had to be updated at least a couple of times. I don't have the old > versions anymore, so I'm just going to say "not my problem" - sorry. Your old 3.18 version :) 8<=== From: Russell King thermal: cpu_cooling: fix lockdep problems in cpu_cooling A recent change to the cpu_cooling code introduced a AB-BA deadlock scenario between the cpufreq_policy_notifier_list rwsem and the cooling_cpufreq_lock. This is caused by cooling_cpufreq_lock being held before the registration/removal of the notifier block (an operation which takes the rwsem), and the notifier code itself which takes the locks in the reverse order. Solve this by moving to finer grained locking - use one mutex to protect the cpufreq_dev_list as a whole, and a separate lock to ensure correct ordering of cpufreq notifier registration and removal. I considered taking the cooling_list_lock within cooling_cpufreq_lock to protect the registration sequence as a whole, but that adds a dependency between these two locks which is best avoided (lest someone tries to take those two new locks in the reverse order.) In any case, it's safer to have an empty cpufreq_dev_list than to have unnecessary dependencies between locks. Fixes: 2dcd851fe4b4 ("thermal: cpu_cooling: Update always cpufreq policy with thermal constraints") Reviewed-by: Viresh Kumar Signed-off-by: Russell King --- drivers/thermal/cpu_cooling.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index ad09e51ffae4..9e42c6f30785 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -57,6 +57,7 @@ static DEFINE_MUTEX(cooling_cpufreq_lock); static unsigned int cpufreq_dev_count; +static DEFINE_MUTEX(cooling_list_lock); static LIST_HEAD(cpufreq_dev_list); /** @@ -317,7 +318,7 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb, if (event != CPUFREQ_ADJUST) return 0; - mutex_lock(&cooling_cpufreq_lock); + mutex_lock(&cooling_list_lock); list_for_each_entry(cpufreq_dev, &cpufreq_dev_list, node) { if (!cpumask_test_cpu(policy->cpu, &cpufreq_dev->allowed_cpus)) @@ -333,7 +334,7 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb, if (policy->max != max_freq) cpufreq_verify_within_limits(policy, 0, max_freq); } - mutex_unlock(&cooling_cpufreq_lock); + mutex_unlock(&cooling_list_lock); return 0; } @@ -482,6 +483,11 @@ __cpufreq_cooling_register(struct device_node *np, } cpufreq_dev->cool_dev = cool_dev; cpufreq_dev->cpufreq_state = 0; + + mutex_lock(&cooling_list_lock); + list_add(&cpufreq_dev->node, &cpufreq_dev_list); + mutex_unlock(&cooling_list_lock); + mutex_lock(&cooling_cpufreq_lock); /* Register the notifier for first cpufreq cooling device */ @@ -489,7 +495,6 @@ __cpufreq_cooling_register(struct device_node *np, cpufreq_register_notifier(&thermal_cpufreq_notifier_block, CPUFREQ_POLICY_NOTIFIER); cpufreq_dev_count++; - list_add(&cpufreq_dev->node, &cpufreq_dev_list); mutex_unlock(&cooling_cpufreq_lock); @@ -553,7 +558,6 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) cpufreq_dev = cdev->devdata; mutex_lock(&cooling_cpufreq_lock); - list_del(&cpufreq_dev->node); cpufreq_dev_count--; /* Unregister the notifier for the last cpufreq cooling device */ @@ -562,6 +566,10 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) CPUFREQ_POLICY_NOTIFIER); mutex_unlock(&cooling_cpufreq_lock); + mutex_lock(&cooling_list_lock); + list_del(&cpufreq_dev->node); + mutex_unlock(&cooling_list_lock); + thermal_cooling_device_unregister(cpufreq_dev->cool_dev); release_idr(&cpufreq_idr, cpufreq_dev->id); kfree(cpufreq_dev);