Issue
There are many RCU functions that don't have a _bh counterpart.
list_entry_rcu()
list_for_each_entry_rcu()
Is this because...
- they can be called from bottom halves just fine (think
list_empty()
vslist_empty_rcu()
)?- Does this mean I can use
rcu_read_lock()
andrcu_read_lock_bh()
interchangeably in these cases?
- Does this mean I can use
- no one has so far needed them (and therefore I's supposed to roll out my own version of them)?
Rule 9 of the RCU checklist says "in which case the matching rcu_dereference()
primitive must be used in order to keep lockdep happy". So I guess the second option above is true. But then I find code that reads like this:
rcu_read_lock_bh();
c = __clusterip_config_find(clusterip);
And then, during __clusterip_config_find()
:
list_for_each_entry_rcu(c, &clusterip_configs, list) {
What is going on!? list_for_each_entry_rcu()
uses rcu_dereference_check()
, not rcu_dereference_bh_check()
...
Solution
This true:
- No one has so far needed them (and therefore I's supposed to roll out my own version of them).
More precise, there is so many RCU list traversal functions, so one decide to not include all their _rcu_bh
counterpairs because of rare needs. But see below.
You cannot use rcu_read_lock()
and rcu_read_lock_bh
interchangably. But difference between rcu_dereference
and rcu_dereference_check
only in annotation: them both expanded to __rcu_dereference_check()
macro call with different c
argument.
So, implementation of __clusterip_config_find
is correct from the processor's view, but may produce warnings when checker is enabled. (Of cource, every driver should tend to work without warnings).
Answered By - Tsyvarev Answer Checked By - Mary Flores (WPSolving Volunteer)