Re: [PATCHv2 2/2] vhost_net: a kernel-level virtio server

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Aug 12, 2009 at 07:11:07AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 12, 2009 at 04:25:40PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Aug 12, 2009 at 09:01:35AM -0400, Gregory Haskins wrote:
> > > I think I understand what your comment above meant:  You don't need to
> > > do synchronize_rcu() because you can flush the workqueue instead to
> > > ensure that all readers have completed.
> > 
> > Yes.
> > 
> > >  But if thats true, to me, the
> > > rcu_dereference itself is gratuitous,
> > 
> > Here's a thesis on what rcu_dereference does (besides documentation):
> > 
> > reader does this
> > 
> > 	A: sock = n->sock
> > 	B: use *sock
> > 
> > Say writer does this:
> > 
> > 	C: newsock = allocate socket
> > 	D: initialize(newsock)
> > 	E: n->sock = newsock
> > 	F: flush
> > 
> > 
> > On Alpha, reads could be reordered.  So, on smp, command A could get
> > data from point F, and command B - from point D (uninitialized, from
> > cache).  IOW, you get fresh pointer but stale data.
> > So we need to stick a barrier in there.
> > 
> > > and that pointer is *not* actually
> > > RCU protected (nor does it need to be).
> > 
> > Heh, if readers are lockless and writer does init/update/sync,
> > this to me spells rcu.
> 
> If you are using call_rcu(), synchronize_rcu(), or one of the
> similar primitives, then you absolutely need rcu_read_lock() and
> rcu_read_unlock(), or one of the similar pairs of primitives.

Right. I don't use any of these though.

> If you -don't- use rcu_read_lock(), then you are pretty much restricted
> to adding data, but never removing it.
> 
> Make sense?  ;-)
> 
> 							Thanx, Paul

Since I only access data from a workqueue, I replaced synchronize_rcu
with workqueue flush. That's why I don't need rcu_read_lock.

-- 
MST