NMIs, Locks, linked lists, barriers, and rculists, oh my!

[michi1@michaelblizek.twilightparadox.com (michi1 at michaelblizek.twilightparadox.com)]

Hi!

On 14:03 Thu 04 Apr     , Arlie Stephens wrote:
...
> On Apr 04 2013, michi1 at michaelblizek.twilightparadox.com wrote:
...
> > On 19:08 Wed 03 Apr     , Arlie Stephens wrote:
...
> > > fix __list_add() so it updates pointers in the new entry before updating
> > > pointers in its neighbours,
> > 
> > IMHO, this is like asking for trouble. Somebody else might change the order
> > in the future without knowing it might break your stuff. Also, if you have bad
> > luck, somebody else might already depend on the current order without you
> > knowing.
> 
> It's notable that __list_add_rcu(), from rculist.h has the order the
> way I want it, even in our elderly kernel version. 
> 
> > You should at least do atomic_read()+atomic_set(). RCU is exactly that plus
> > a mechanism to free memory after all readers have finished.
> 
> Now I'm confused. It seems to me that part of RCU's contribution is
> use of barrier instructions (compiler and run-time) at appropriate
> points. Are you saying that atomic_read() and atomic_set() have
> implicit barriers? 

You are right, it seems like atomic ops do not imply barriers:
Documentation/atomic_ops.txt

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com