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

From: Paul E. McKenney
Date: Wed Aug 12 2009 - 10:11:30 EST


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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/