[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOrHB_AWB7MFEHpeuKcG21s9QWjMHKC2zWNmXQLDo_5KZrnY6w@mail.gmail.com>
Date: Mon, 6 Feb 2017 09:06:29 -0800
From: Pravin Shelar <pshelar@....org>
To: David Miller <davem@...emloft.net>
Cc: Jarno Rajahalme <jarno@....org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/7] openvswitch: Use inverted tuple in
ovs_ct_find_existing() if NATted.
On Sun, Feb 5, 2017 at 2:28 PM, David Miller <davem@...emloft.net> wrote:
> From: Jarno Rajahalme <jarno@....org>
> Date: Thu, 2 Feb 2017 17:10:00 -0800
>
>> This does not match either of the conntrack tuples above. Normally
>> this does not matter, as the conntrack lookup was already done using
>> the tuple (B,A), but if the current packet does not match any flow in
>> the OVS datapath, the packet is sent to userspace via an upcall,
>> during which the packet's skb is freed, and the conntrack entry
>> pointer in the skb is lost.
>
> This is the real bug.
>
> If the metadata for a packet is important, as it obviously is here,
> then upcalls should preserve that metadata across the upcall. This
> is exactly how NF_QUEUE handles this problem and so should OVS.
OVS kernel datapath serializes skb context and sends it along with skb
during upcall via genetlink parameters. userspace echoes same
information back to kernel modules. This way OVS does maintains
metadata across upcall.
Powered by blists - more mailing lists