RCU part 3: the RCU API

Posted Jan 24, 2008 9:46 UTC (Thu) by jarkao2 (guest, #41960)
Parent article: RCU part 3: the RCU API

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!

RCU part 3: the RCU API

Posted Jan 31, 2008 2:04 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (2 responses)

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

Posted Jan 31, 2008 2:34 UTC (Thu) by ris (subscriber, #5) [Link] (1 responses)

> Good catch! s/an the/the/

Fixed!

RCU part 3: the RCU API

Posted Jan 31, 2008 11:18 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Thank you very much!!!