Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755163AbcKJBhE (ORCPT ); Wed, 9 Nov 2016 20:37:04 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:35346 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754586AbcKJBhC (ORCPT ); Wed, 9 Nov 2016 20:37:02 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 6183F61359 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=sboyd@codeaurora.org Date: Wed, 9 Nov 2016 17:37:00 -0800 From: Stephen Boyd To: Viresh Kumar Cc: Rafael Wysocki , nm@ti.com, Viresh Kumar , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , robh@kernel.org, d-gerlach@ti.com, broonie@kernel.org Subject: Re: [PATCH V2 5/8] PM / OPP: Add infrastructure to manage multiple regulators Message-ID: <20161110013700.GX16026@codeaurora.org> References: <32c1feabb59b1f00e1cefde606e3ec7ef738ac12.1476952750.git.viresh.kumar@linaro.org> <20161025164953.GT26139@codeaurora.org> <20161026060512.GI9162@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161026060512.GI9162@vireshk-i7> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2148 Lines: 52 On 10/26, Viresh Kumar wrote: > On 25-10-16, 09:49, Stephen Boyd wrote: > > On 10/20, Viresh Kumar wrote: > > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c > > > index 37fad2eb0f47..45c70ce07864 100644 > > > --- a/drivers/base/power/opp/core.c > > > +++ b/drivers/base/power/opp/core.c > > > @@ -235,21 +237,44 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev) > > > return 0; > > > } > > > > > > - reg = opp_table->regulator; > > > - if (IS_ERR(reg)) { > > > + count = opp_table->regulator_count; > > > + > > > + if (!count) { > > > /* Regulator may not be required for device */ > > > rcu_read_unlock(); > > > return 0; > > > } > > > > > > - list_for_each_entry_rcu(opp, &opp_table->opp_list, node) { > > > - if (!opp->available) > > > - continue; > > > + size = count * sizeof(*regulators); > > > + regulators = kmemdup(opp_table->regulators, size, GFP_KERNEL); > > > > How do we allocate under RCU? Doesn't that spit out big warnings? > > That doesn't. I even tried enabling several locking debug config options. Please read RCU documentation. From rcu_read_lock() function documentation: In non-preemptible RCU implementations (TREE_RCU and TINY_RCU), it is illegal to block while in an RCU read-side critical section. In preemptible RCU implementations (TREE_PREEMPT_RCU) in CONFIG_PREEMPT kernel builds, RCU read-side critical sections may be preempted, but explicit blocking is illegal. Finally, in preemptible RCU implementations in real-time (with -rt patchset) kernel builds, RCU read-side critical sections may be preempted and they may also block, but only when acquiring spinlocks that are subject to priority inheritance. I suppose that in certain configurations it will warn and in others it won't. I thought lockdep would always complain though, so that's sad it doesn't. At least in some implementations of RCU rcu_read_lock() is the same as preempt_disable(), which basically means no sleeping calls like GFP_KERNEL allocations. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project