From patchwork Wed Sep 20 20:25:28 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 9962387 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6BA4D601D5 for ; Wed, 20 Sep 2017 20:25:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5EEA8291BB for ; Wed, 20 Sep 2017 20:25:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 53D3B291E5; Wed, 20 Sep 2017 20:25:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0F6FB291BB for ; Wed, 20 Sep 2017 20:25:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751465AbdITUZd (ORCPT ); Wed, 20 Sep 2017 16:25:33 -0400 Received: from mail-pf0-f171.google.com ([209.85.192.171]:44547 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751450AbdITUZc (ORCPT ); Wed, 20 Sep 2017 16:25:32 -0400 Received: by mail-pf0-f171.google.com with SMTP id e1so2093476pfk.1 for ; Wed, 20 Sep 2017 13:25:32 -0700 (PDT) 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; bh=DYggL3hLhyMr9D9/jmdhIEIBQvPM/Rlb+VdBAZpgkCw=; b=PpfwGzQ5mTESSJsC5uvneaBKR0afO97SVmyWxWw9FaCqvawGWXe5SgfdTfDdSoCR3A N77mgZHRfZ1xQ0qYHxEnVsn5+28sPbLiHIaVmcHY/ooxwTPLLLpFxsi6dtEMvuHkq9TG PaLFLbcVzXILmL5uJVMK4VllCpTdhJG2fHdrM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=DYggL3hLhyMr9D9/jmdhIEIBQvPM/Rlb+VdBAZpgkCw=; b=DG51zRa9+LfKCOVbUA0hc+j4pmbRNcNwkg8QxshfN1Z9wwuGwhXjZ1bhQgrRR+Vioa /rZMrt3B2Rm4h6p+3Fgbr0ExqsyfNu62t53+GitlaD7ttRc8A1+6URzEF8VXXf6Gaq+p tOdYhkJDWACfTVIsc3a0dg2FFTulrbdo8hs+2Ed5IFH/hS2dvfGHbEutBTiBs89fj9qs U0LbVQwAh+6uRk3kqE+PcrMyffOqfnpwkshUDYoeKTl+0kIthtpy7Ym55sQY45vk8FTl nXuYvykcPac4re73PolahU7W0iYx9FSKNkBRIRcF+t+s1wQ9m3DsxX/Of+U3sDpH8VuT 3K0A== X-Gm-Message-State: AHPjjUjZUgmPgHzCm/bs9TVON1Mv3HakU33raWymYv02Y6c+a8uzze0q V7SFTX3YOjGhsGGupuJLnneE3Q== X-Google-Smtp-Source: AOwi7QDRNGbr8l+KEN1nDGGWYi7wZ03CGO1NJz2u+f+Kt74poNWWpq1kspsEMKkyjSiPUf0h29+1nw== X-Received: by 10.98.57.129 with SMTP id u1mr3331398pfj.197.1505939131881; Wed, 20 Sep 2017 13:25:31 -0700 (PDT) Received: from localhost (cpe-172-88-64-62.socal.res.rr.com. [172.88.64.62]) by smtp.gmail.com with ESMTPSA id r68sm9453926pfi.7.2017.09.20.13.25.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 13:25:31 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , cw00.choi@samsung.com, Viresh Kumar , Nishanth Menon , Stephen Boyd Cc: Viresh Kumar , linux-pm@vger.kernel.org, Vincent Guittot , myungjoo.ham@samsung.com, inki.dae@samsung.com, linux-kernel@vger.kernel.org Subject: [PATCH V2] PM / OPP: Call notifier without holding opp_table->lock Date: Wed, 20 Sep 2017 13:25:28 -0700 Message-Id: <5b70f7bdf12975f869a83f77e36bf3a40e0fa4b9.1505939072.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <59C2414E.6020803@samsung.com> References: <59C2414E.6020803@samsung.com> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The notifier callbacks may want to call some OPP helper routines which may try to take the same opp_table->lock again and cause a deadlock. One such usecase was reported by Chanwoo Choi, where calling dev_pm_opp_disable() leads us to the devfreq's OPP notifier handler, which further calls dev_pm_opp_find_freq_floor() and it deadlocks. We don't really need the opp_table->lock to be held across the notifier call though, all we want to make sure is that the 'opp' doesn't get freed while being used from within the notifier chain. We can do it with help of dev_pm_opp_get/put() as well. Let's do it. Reported-by: Chanwoo Choi Reviewed-by: Stephen Boyd Signed-off-by: Viresh Kumar Tested-by: Chanwoo Choi Reviewed-by: Chanwoo Choi --- V1->V2: - s/Lets/Let's/ in commit log and added Stephen's tag. drivers/base/power/opp/core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c index 4360b4efcd4c..668fd940d362 100644 --- a/drivers/base/power/opp/core.c +++ b/drivers/base/power/opp/core.c @@ -1627,6 +1627,9 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, opp->available = availability_req; + dev_pm_opp_get(opp); + mutex_unlock(&opp_table->lock); + /* Notify the change of the OPP availability */ if (availability_req) blocking_notifier_call_chain(&opp_table->head, OPP_EVENT_ENABLE, @@ -1635,8 +1638,12 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, blocking_notifier_call_chain(&opp_table->head, OPP_EVENT_DISABLE, opp); + dev_pm_opp_put(opp); + goto put_table; + unlock: mutex_unlock(&opp_table->lock); +put_table: dev_pm_opp_put_opp_table(opp_table); return r; }