On Wed, Mar 18, 2020 at 02:57:53PM +0100, Ilya Maximets wrote: > On 3/5/20 12:28 PM, Dumitru Ceara wrote: > > When a new conntrack zone is entered, the ct_state field is zeroed in > > order to avoid using state information from different zones.
... > Regarding the issue. I've spent some time exploring the conntrack code > and also researching the original patch that introduced this code. > The issue was raised during the review of the original patch 286de2729955 > by Daniele: https://patchwork.ozlabs.org/patch/743108/ > And Darrell said that he actually had the similar code that clears ct_state > during zone transition at the beginning of process_one(). But, he decided > that most of such issues are likely configuration bugs that should by raised > to user with warnings. > However, such warnings was never introduced and since this causes a real > issue in OVN we should actually have this clearing of conntrack state on > zone transitioning. > > Acked-by: Ilya Maximets <[email protected]> > > Darrell, Ben, I'd like to have some comments on this from you since I'm > not an expert in this area. Otherwise, I'm going to apply this patch on > next week. I *think* that this new behavior matches that of the kernel datapath. In __ovs_ct_lookup(), I believe that a change in zone would cause skb_nfct_cached() to return false, causing the code to reset ct_state to 0. If so, then it makes sense for the userspace datapath to behave similarly. Darrell? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
