On 6/14/2011 9:08 PM, Menon, Nishanth wrote:
On Tue, Jun 14, 2011 at 08:03, Santosh Shilimkar <santosh.shilimkar@xxxxxx> wrote:With RCU debug options enabled, below warning is observed. =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- drivers/base/power/opp.c:151 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1. ... --------------------------------------------------- Fix the same by protecting it with rcu_read lock. Signed-off-by: Santosh Shilimkar<santosh.shilimkar@xxxxxx> Cc: Rafael J. Wysocki<rjw@xxxxxxx> Cc: Nishanth Menon<nm@xxxxxx> Cc: Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx> --- drivers/base/power/opp.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c index 56a6899..cbed5e1 100644 --- a/drivers/base/power/opp.c +++ b/drivers/base/power/opp.c @@ -148,7 +148,9 @@ unsigned long opp_get_voltage(struct opp *opp) struct opp *tmp_opp; unsigned long v = 0; + rcu_read_lock(); tmp_opp = rcu_dereference(opp); + rcu_read_unlock(); if (unlikely(IS_ERR_OR_NULL(tmp_opp)) || !tmp_opp->available) pr_err("%s: Invalid parameters\n", __func__); elseNAK. please read the Documentation/power/opp.txt the usage is as follows: rcu_read_lock(); opp = opp_find_freq_ceil(); voltage = opp_get_voltage(opp); rcu_read_unlock(); the reason for this is that the opp pointer is not safe if we lock just the dereferencing.
Fair enough. if the whole fn is under the lock then it's not necessary. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
