LWN: Comments on "RCU part 3: the RCU API"

RCU part 3: the RCU API

PaulMcKenney — 2008-01-31T11:18:49+00:00

Thank you very much!!!

RCU part 3: the RCU API

ris — 2008-01-31T02:34:59+00:00

> Good catch! s/an the/the/

Fixed!

RCU part 3: the RCU API

PaulMcKenney — 2008-01-31T02:04:44+00:00

Good questions! Point-by-point answers:

Your example might or might not be legal, depending on what primitive you used to wait for a grace period. If you are using call_rcu() or synchronize_rcu(), your example is technically illegal for Classic RCU and prone to failure for realtime RCU. If you are using synchronize_srcu(), your example is technically illegal, but will work given the current implementation. If you are using call_rcu_bh() or synchronize_qrcu(), your example is illegal and prone to failure. Finally, if you are using synchronize_sched(), your example is entirely legal, because preempt_disable() introduces an RCU read-side critical section. You could create a similar list for your _ bh example. But please note that if I see anyone submitting a patch in the "technically illegal but works" category, I will NACK it.
One could indeed have listed more things in that cell: no _bh enabling, no blocking, and, as you say, no softirq enabling. The reason that there is not yet an rcu_bh_barrier() is that there has not been a clear need for it yet -- which might change if someone needs call_rcu_bh() in a module.
Good catch! s/an the/the/

RCU part 3: the RCU API

jarkao2 — 2008-01-24T09:46:39+00:00

Hi, here are my doubts and suggestions of tiny fixes:

1. Probably in part 1 there was mention of using RCU pointers after their read-side block
being illegal; maybe it was explained later, but I would like to be sure about such cases:

  RCU Classic
================
preempt_disable()
or spin_lock()
    ...
rcu_read_lock()
    ...
p = rcu_dereference()
    ...
rcu_read_unlock()
    ...
rcu_read_lock()
    ...
r = p->something
    ...
rcu_read_unlock()
    ...
preempt_enable()
or spin_unlock()

(this code could be divided between 2 functions, BTW)

or similarly with RCU BH, but with local_bh_disable/enable() instead of
preempt_disable/enable() and with rcu_read_lock/unlock_bh()

So, is it 'legal' if we don't care about RT problems with this?

2. In the first table here for RCU BH shouldn't this be "No soft irq enabling"? (And why
rcu_barrier() missing?)

3. And traditionally 'an' fix proposal: (under second table) "but incur an the overhead".
(Quick Quiz 10?)

Many thanks again!