On Tue, Jun 14, 2011 at 08:03, Santosh ShilimkarFair enough. if the whole fn is under the lock then it's not
<santosh.shilimkar@xxxxxx> wrote:
With RCU debug options enabled, below warning is observed.NAK. please read the Documentation/power/opp.txt
===================================================
[ 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__);
else
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.