Some usages of RCU in the kernel code

The reason that kernel/kprobes.c does not use synchronize_rcu() is that it instead uses synchronize_sched(). The read-side primitives corresponding to synchronize_sched() include preempt_disable()/preempt_enable(), local_irq_save()/local_irq_restore() -- in short, any primitive that disables and re-enables preemption, including entry to hardware irq/exception handlers. The third article in this series will cover these and other nuances of the RCU API.

The reason that __list_add_rcu() does not use rcu_dereference() is that __list_add_rcu() is an update-side primitive, and therefore must be protected by appropriate locking. This means that the list cannot change while the lock is held, and this in turn means that the memory barriers implied by lock acquisition suffice. That said, it is permissible (but again, not necessary) to use rcu_dereference() in update-side code -- in fact, in some situations, doing so promotes code reuse and in some cases readability.

The discussion of Figure 2 in this article and its bibliography is a good place to start on Alpha's memory ordering. I am not all that familiar with value-speculation compiler-optimization research, but one place to start might be here.

Regarding the second point, I'm sorry, my fingers typed rcu_dereference() whereas my brain was
thinking to rcu_assign_pointer(). rcu_dereference() could be used in update-side code, as you
pointed out, but obviously not in __list_add_rcu().

Therefore __list_add_rcu() could be:

        new->next = next;
        new->prev = prev;
        rcu_assign_pointer(prev->next, new);
        next->prev = new;

The main advantage of this is readability IMHO.

You said that __list_add_rcu() must be protected by appropriate locking, and a memory barrier
is implied by lock acquisition which should be enough. But __list_add_rcu() has a memory
barrier in its implementation.

Thanks.

Good point!  Would you like to submit a patch?

Well, I actually raised 2 points and I'm not sure which one is the good one...

Could you please clarify ?

To answer your question, I don't have any problems for submitting a patch.

---
PS: This interface is pretty hard for discussing on an article. It's like bottom-posting
except we loose all its advantages... Just my 2 cents.

I was inviting a patch for incorporating the smp_wmb() into the rcu_assign_pointer.

The lock acquisition makes rcu_dereference() unnecessary, but cannot enforce the ordering
provided by the smp_wmb()/rcu_assign_pointer().

Thanks for this (next) great article too! BTW, probably 'a' tiny fix needed:
"Maintain Multiple Versions of Recently Updated Objects
[...] Two examples are presented showing how a an element [...]"

Good eyes!!!