From mboxrd@z Thu Jan  1 00:00:00 1970
From: michi1@michaelblizek.twilightparadox.com (michi1 at michaelblizek.twilightparadox.com)
Date: Fri, 5 Apr 2013 07:28:14 +0200
Subject: NMIs, Locks, linked lists, barriers, and rculists, oh my!
In-Reply-To: <20130404210312.GA16275@worldash.org>
References: <20130404020845.GA9667@worldash.org> <20130404171057.GB2256@grml>
	<20130404210312.GA16275@worldash.org>
Message-ID: <20130405052813.GA2240@grml>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

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