CODEWITHSUNDEEP
linux-kernelrcu
Yd Ahhrk
Yd Ahhrk

Reputation: 1138

What should I do with nonexistent _bh RCU functions?

There are many RCU functions that don't have a _bh counterpart.

Examples are:

Is this because...

  1. they can be called from bottom halves just fine (think list_empty() vs list_empty_rcu())?
    • Does this mean I can use rcu_read_lock() and rcu_read_lock_bh() interchangeably in these cases?
  2. 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()...

Upvotes: 1

Views: 168

Answers (1)

Tsyvarev
Tsyvarev

Reputation: 65976

This true:

  1. 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).

Upvotes: 1

Related Questions