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