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

Michael S. Tsirkin
2009-08-12T13:47:15Z

On Wed, Aug 12, 2009 at 09:41:35AM -0400, Gregory Haskins wrote:
> 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.
>
> Yes, that is understood. Perhaps you should just use a normal barrier,
> however. (Or at least a comment that says "I am just using this for its
> barrier").
>
> >
> >> 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.
>
> More correctly: it "smells like" RCU, but its not. ;) It's rcu-like,
> but you are not really using the rcu facilities. I think anyone that
> knows RCU and reads your code will likely be scratching their heads as well.
>
> Its probably not a big deal, as I understand your code now. Just a
> suggestion to help clarify it.
>
> Regards,
> -Greg
>

OK, I'll add some comments about that.
Thanks for the review!

--
MST