Some usages of RCU in the kernel code

Posted Jan 7, 2008 10:14 UTC (Mon) by fbh (guest, #49754)
In reply to: Some usages of RCU in the kernel code by PaulMcKenney
Parent article: What is RCU, Fundamentally?

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.

Some usages of RCU in the kernel code

Posted Jan 7, 2008 15:28 UTC (Mon) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (2 responses)

Good point!  Would you like to submit a patch?

Some usages of RCU in the kernel code

Posted Jan 7, 2008 16:03 UTC (Mon) by fbh (guest, #49754) [Link] (1 responses)

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.

Some usages of RCU in the kernel code

Posted Jan 7, 2008 16:52 UTC (Mon) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

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