[ovs-dev] [PATCH 2/3] [bug 2462] flex-array: Add memory barriers to flex array updates.

Jesse Gross jesse at nicira.com
Tue Feb 7 03:33:08 UTC 2012


On Mon, Feb 6, 2012 at 6:50 PM, Pravin Shelar <pshelar at nicira.com> wrote:
> On Mon, Feb 6, 2012 at 3:25 PM, Jesse Gross <jesse at nicira.com> wrote:
>> I think the biggest problem here is that there's no clear
>> documentation on what guarantees we're providing.  There's two
>> possibilities that I see: that the flex array data structure itself is
>> safe to read as it is being expanded on a different CPU or that both
>> the data structure and the data being written are safe.  For our
>> purposes we only care about the former because the data are pointers
>> and we can initialize it to zero so everything is atomic.  The latter
>> is impossible to enforce for arbitrary data with the way that flex
>> arrays are set up because after a part is allocated there's no pointer
>> write to create an atomic switch with which we can enforce ordering.
>> It looks like the RCU primitives that you used protect the structure
>> itself and the open coded components are trying to protect the data.
>>
> ok, It will not work when non pointer data is stored in flex_array. I
> will move mem barrier to caller.

Yes, if this is enforcing locking for the caller then it needs to be
done by the caller.  However, since this is using RCU it needs to use
the RCU API without exception.  If that's not possible then the
flex_array API needs to be changed (I think a pointer model is better
than the current one based on copying).



More information about the dev mailing list