On Sun, Mar 01, 2015 at 02:02:23PM +0000, Mathieu Desnoyers wrote: > > + * So during the modification, queries are first redirected to data[1]. > > Then we > > + * modify data[0]. When that is complete, we redirect queries back to > > data[0] > > + * and we can modify data[1]. > > + * > > + * NOTE: The non-requirement for atomic modifications does _NOT_ include > > + * the publishing of new entries in the case where data is a dynamic > > + * data structure. > > + * > > + * An iteration might start in data[0] and get suspended long enough > > + * to miss an entire modification sequence, once it resumes it might > > + * observe the new entry. > > We might want to hint that in the case of dynamic data structures, > RCU read-side C.S. and grace period should be used together with the > latch to handle the object teardown.
Can do. > The latch, AFAIU, takes care of making sure the new objects are > initialized before being published into the data structure, so there > would be no need to use RCU assign pointer. However, we really need > RCU around reads, along with a grace period between removal of an object > and its teardown. So I do need the rcu_assign_pointer for the RB link because that also initializes the rb_node itself. Or put differently, be _very_ _VERY_ sure your entire object is initialized before the latch. Secondly, note that the latch does a WMB and rcu_assign_pointer does a RELEASE, these are not equivalent. So I don't think I will highlight this particular point. If you're sure enough to know the difference you can get away with it, sure. But in general I think people should still use rcu_assign_pointer; if only to make Paul sleep better at night ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/