Messages in this thread | | | Date | Wed, 12 Aug 2009 09:41:35 -0400 | From | Gregory Haskins <> | Subject | Re: [PATCHv2 2/2] vhost_net: a kernel-level virtio server |
| |
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
[unhandled content-type:application/pgp-signature] | |