From patchwork Mon Dec 15 13:28:41 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Yadwinder Singh Brar X-Patchwork-Id: 421200 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id EDAC21400D2 for ; Tue, 16 Dec 2014 00:31:07 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y0Vhd-0008IM-03; Mon, 15 Dec 2014 13:28:45 +0000 Received: from mailout4.samsung.com ([203.254.224.34]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y0VhY-0008E8-EK for linux-arm-kernel@lists.infradead.org; Mon, 15 Dec 2014 13:28:41 +0000 Received: from epcpsbgr4.samsung.com (u144.gpu120.samsung.co.kr [203.254.230.144]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NGM00A48LF30G40@mailout4.samsung.com> for linux-arm-kernel@lists.infradead.org; Mon, 15 Dec 2014 22:28:15 +0900 (KST) Received: from epcpsbgm2.samsung.com ( [172.20.52.122]) by epcpsbgr4.samsung.com (EPCPMTA) with SMTP id F8.C0.18167.FE1EE845; Mon, 15 Dec 2014 22:28:15 +0900 (KST) X-AuditID: cbfee690-f79ab6d0000046f7-66-548ee1ef1c82 Received: from epmmp2 ( [203.254.227.17]) by epcpsbgm2.samsung.com (EPCPMTA) with SMTP id 09.28.09430.FE1EE845; Mon, 15 Dec 2014 22:28:15 +0900 (KST) Received: from yadibrar ([107.108.83.73]) by mmp2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0NGM00052LEDGRX0@mmp2.samsung.com>; Mon, 15 Dec 2014 22:28:14 +0900 (KST) From: Yadwinder Singh Brar To: 'Viresh Kumar' , "'Rafael J. Wysocki'" References: <20141214213655.GA11285@n2100.arm.linux.org.uk> <7573578.UE8ufgjWuX@vostro.rjw.lan> In-reply-to: Subject: RE: 3.18: lockdep problems in cpufreq Date: Mon, 15 Dec 2014 18:58:41 +0530 Message-id: <002f01d0186b$2700b730$75022590$%brar@samsung.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AdAYGy6sbw5rqx9nQA2mZeXLUgCG/QATL6GQ Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsWyRsSkSvf9w74Qgy1LhSzmX7nGarHpMZD4 3HuE0eL2ZV6LM6cvsVps/OrhwObR0tzD5rFz1l12jzvX9rB5bF5S77HlajuLx+dNcgFsUVw2 Kak5mWWpRfp2CVwZ+1ZfYC9YqVXRuSCmgfG1fBcjJ4eEgIlE8+ZpTBC2mMSFe+vZuhi5OIQE ljJKrPm/lB2m6PrRo6wQiemMElc/X2aBcH4ySnzZ/BzI4eBgEzCWOHuTG8QUEYiUWH/IDqSE GWTQtF9LmSDqVzBKXLjRBjaVUyBY4tDHF2wgtrCAnsSxF7fBzmARUJXYPnsuWJxXwE7i1fwN rBC2oMSPyfdYQGxmAXWJSfMWMUPY2hJP3l1gBVksARR/9FcX4gYjiQML7CAqxCUmPXjIDnKC hMA9don2f69YIFYJSHybfIgFolVWYtMBZoh/JSUOrrjBMoFRYhaSxbOQLJ6FZPEsJCsWMLKs YhRNLUguKE5KLzLRK07MLS7NS9dLzs/dxAiM2tP/nk3YwXjvgPUhRgEORiUe3kjGvhAh1sSy 4srcQ4ymQBdNZJYSTc4Hpoa8knhDYzMjC1MTU2Mjc0szJXHe11I/g4UE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwmhxeNWdm1irNmCDe6gPblzZk/Nn/I1l2kvIa1hCxoP1l/DHr+9a+/s3t 8+LiEc1vB8PKJnpN3PrnC3P5twWu7NNKHudP4vyjxWMw+1jK6eLPorZOdutes0nUTjv9eZpo cIWHzX2ZvfdNl3cY5yzepcL+44FTyZTbrFbS1jOCj/6ZHxxZtfDcXyWW4oxEQy3mouJEACD7 MhbVAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42I5/e+xoO77h30hBt2LOCzmX7nGarHpMZD4 3HuE0eL2ZV6LM6cvsVps/OrhwObR0tzD5rFz1l12jzvX9rB5bF5S77HlajuLx+dNcgFsUQ2M NhmpiSmpRQqpecn5KZl56bZK3sHxzvGmZgaGuoaWFuZKCnmJuam2Si4+AbpumTlARygplCXm lAKFAhKLi5X07TBNCA1x07WAaYzQ9Q0JgusxMkADCWsYM/atvsBesFKronNBTAPja/kuRk4O CQETietHj7JC2GISF+6tZ+ti5OIQEpjOKHH182UWCOcno8SXzc+BHA4ONgFjibM3uUFMEYFI ifWH7EBKmAWWMkpM+7WUCaJ+BaPEhRtt7CBTOQWCJQ59fMEGYgsL6Ekce3GbCcRmEVCV2D57 LlicV8BO4tX8DawQtqDEj8n3WEBsZgF1iUnzFjFD2NoST95dYAVZLAEUf/RXF+IGI4kDC+wg KsQlJj14yD6BUWgWkkGzkAyahWTQLCQtCxhZVjGKphYkFxQnpeca6RUn5haX5qXrJefnbmIE p4Rn0jsYVzVYHGIU4GBU4uFl+N8bIsSaWFZcmXuIUYKDWUmEt+1+X4gQb0piZVVqUX58UWlO avEhRlOgPycyS4km5wPTVV5JvKGxibmpsamliYWJmaWSOK+SfVuIkEB6YklqdmpqQWoRTB8T B6dUA2MP02Te6O+XytbvzLBbYGoYPVFitaqd2O55xRNnTNphxRbAUSgZKlCdubD0b9sEtYVG PFYK3+5Ofh2+NFfQc9anRLeNla+Vp9jvSXtiKfFhVtPWA0klVWtcM6PuGaeLqG+axqNv17Wq OS1tu+jJAjmvhLna/9yYVCadPLVSZ1W90OTeTUvTjJRYijMSDbWYi4oTAbQjV14fAwAA DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141215_052840_635386_CF3F513F X-CRM114-Status: GOOD ( 27.61 ) X-Spam-Score: -5.0 (-----) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-5.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [203.254.224.34 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [203.254.224.34 listed in wl.mailspike.net] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders Cc: 'Eduardo Valentin' , 'Russell King - ARM Linux' , linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org > -----Original Message----- > From: Viresh Kumar [mailto:viresh.kumar@linaro.org] > Sent: Monday, December 15, 2014 9:27 AM > To: Rafael J. Wysocki; yadi.brar@samsung.com > Cc: Russell King - ARM Linux; linux-arm-kernel@lists.infradead.org; > linux-pm@vger.kernel.org; Eduardo Valentin > Subject: Re: 3.18: lockdep problems in cpufreq > > On 15 December 2014 at 03:53, Rafael J. Wysocki > wrote: > > On Sunday, December 14, 2014 09:36:55 PM Russell King - ARM Linux > wrote: > >> Here's a nice Christmas present one of my iMX6 machines gave me > tonight. > >> I haven't begun to look into it. > > Is the culprit this one? > > Fixes: 2dcd851fe4b4 ("thermal: cpu_cooling: Update always cpufreq > policy with thermal constraints") > > As this is what it changed: > > @@ -316,21 +312,28 @@ static int cpufreq_thermal_notifier(struct > notifier_block *nb, { > struct cpufreq_policy *policy = data; > unsigned long max_freq = 0; > + struct cpufreq_cooling_device *cpufreq_dev; > > - if (event != CPUFREQ_ADJUST || notify_device == NOTIFY_INVALID) > + if (event != CPUFREQ_ADJUST) > return 0; > > - if (cpumask_test_cpu(policy->cpu, ¬ify_device- > >allowed_cpus)) > - max_freq = notify_device->cpufreq_val; > - else > - return 0; > + mutex_lock(&cooling_cpufreq_lock); > + list_for_each_entry(cpufreq_dev, &cpufreq_dev_list, node) { > + if (!cpumask_test_cpu(policy->cpu, > + &cpufreq_dev->allowed_cpus)) > + continue; > + > + if (!cpufreq_dev->cpufreq_val) > + cpufreq_dev->cpufreq_val = get_cpu_frequency( > + cpumask_any(&cpufreq_dev- > >allowed_cpus), > + cpufreq_dev->cpufreq_state); > > - /* Never exceed user_policy.max */ > - if (max_freq > policy->user_policy.max) > - max_freq = policy->user_policy.max; > + max_freq = cpufreq_dev->cpufreq_val; > > - if (policy->max != max_freq) > - cpufreq_verify_within_limits(policy, 0, max_freq); > + if (policy->max != max_freq) > + cpufreq_verify_within_limits(policy, 0, > max_freq); > + } > + mutex_unlock(&cooling_cpufreq_lock); > > return 0; > } > > > >> ====================================================== > >> [ INFO: possible circular locking dependency detected ] 3.18.0+ > #1453 > >> Not tainted > >> ------------------------------------------------------- > >> rc.local/770 is trying to acquire lock: > >> (cooling_cpufreq_lock){+.+.+.}, at: [] > >> cpufreq_thermal_notifier+0x34/0xfc > >> > >> but task is already holding lock: > >> ((cpufreq_policy_notifier_list).rwsem){++++.+}, at: [] > >> __blocking_notifier_call_chain+0x34/0x68 > >> > >> which lock already depends on the new lock. > > > > Well, that's for Viresh. > > Maybe not as the rework I have done is queued for this merge window. > I was afraid really after reading the "offenders" discussion on IRC :) > > Cc'd Yadwinder as well who wrote this patch. Thanks :). Unfortunately, I didn’t get any such warning though I tested patch enabling CONFIG_PROVE_LOCKING before posting. It seems Russell is trying to load imx_thermal as module and parallely Changing cpufreq governor from userspace, which was not my test case. Anyways, after analyzing log and code,I think problem is not in cpufreq_thermal_notifier which was modified in patch as stated above. Actual problem is in __cpufreq_cooling_register which is unnecessarily calling cpufreq_register_notifier() inside section protected by cooling_cpufreq_lock. Because cpufreq_policy_notifier_list).rwsem is already held by store_scaling_governor when __cpufreq_cooling_register is trying to cpufreq_policy_notifier_list while holding cooling_cpufreq_lock. So I think following can fix the problem: Best Regards, Yadwinder Reviewed-by: Viresh Kumar diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index ad09e51..622ea40 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -484,15 +484,15 @@ __cpufreq_cooling_register(struct device_node *np, cpufreq_dev->cpufreq_state = 0; mutex_lock(&cooling_cpufreq_lock); - /* Register the notifier for first cpufreq cooling device */ - if (cpufreq_dev_count == 0) - 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); + /* Register the notifier for first cpufreq cooling device */ + if (cpufreq_dev_count == 0) + cpufreq_register_notifier(&thermal_cpufreq_notifier_block, + CPUFREQ_POLICY_NOTIFIER); return cool_dev; }