On Wed, May 08, 2019 at 12:14:56AM -0700, Darrell Ball wrote: > On Tue, May 7, 2019 at 2:56 PM Ben Pfaff <[email protected]> wrote: > > I am not confident about destruction ordering here. It appears that > > conntrack_destroy() frees 'ct'. I don't see anything that assures that > > a grace period has expired before this. In the meantime, it seems that > > packet processing could access 'ct'. I think that the same is true for, > > e.g., ct_lock. I guess one way it could be safe if is > > conntrack_destroy() requires the caller to have already quiesced packet > > processing for a grace period, but that doesn't seem to be documented > > and I don't think dpif-netdev does that. > > > > 'dp_netdev_free' destroys all the ports and then pmds before calling > conntrack_destroy().
OK, I see that now, thank you. So I guess conntrack_destroy() does rely on the caller having quiesced packet processing before destroying the conntrack. That is fine, but I think that it should be documented in a comment on conntrack_destroy(), because naively in the presence of RCU one might expect that stray packets might still squeak through. > I think memory barriers are already implied; meaning, I do NOT think > something like the following is needed, although it does no harm. I agree. > ovsrcu_synchronize() is also not needed here. Is there any chance that already-completed packet processing might have done ovsrcu_postpone() to RCU-free data structures, and that those might be deferred until after conntrack_destroy() begins, and that they might access freed or otherwise corrupt memory due to the conntrack destruction? If that is not possible--I have not checked--then I agree. Thanks, Ben. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
