[ovs-dev] [PATCH v2] conntrack: Reset ct_state when entering a new zone.

Ben Pfaff blp at ovn.org
Wed Mar 18 15:30:28 UTC 2020


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 <i.maximets at ovn.org>
> 
> 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?


More information about the dev mailing list