All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pravin Shelar <pshelar@ovn.org>
To: David Miller <davem@davemloft.net>
Cc: Jarno Rajahalme <jarno@ovn.org>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 1/7] openvswitch: Use inverted tuple in ovs_ct_find_existing() if NATted.
Date: Tue, 7 Feb 2017 09:14:26 -0800	[thread overview]
Message-ID: <CAOrHB_AOYrzDVZBST-TDZo2ZtrBqQiv6+0eHNDJuukGUDYGZFQ@mail.gmail.com> (raw)
In-Reply-To: <20170206.121512.1686451353447088557.davem@davemloft.net>

On Mon, Feb 6, 2017 at 9:15 AM, David Miller <davem@davemloft.net> wrote:
> From: Pravin Shelar <pshelar@ovn.org>
> Date: Mon, 6 Feb 2017 09:06:29 -0800
>
>> On Sun, Feb 5, 2017 at 2:28 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Jarno Rajahalme <jarno@ovn.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.
>
> Then the conntrack state looked up before the NAT operation done in
> the upcall should be maintained and therefore this bug should not
> exist.

I think it fails because after upcall OVS is performing lookup for
nonexistent conntrack entry. This is due to the fact that the packet
is already Nat-ed. So one could argue that there is already enough
context available in OVS to lookup original conntract entry after the
upcall as shown in this patch.
But I am also fine with using original context to lookup the conntract
entry as Joe has suggested.

  reply	other threads:[~2017-02-07 17:14 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03  1:10 [PATCH net-next 1/7] openvswitch: Use inverted tuple in ovs_ct_find_existing() if NATted Jarno Rajahalme
2017-02-03  1:10 ` [PATCH net-next 2/7] openvswitch: Unionize ovs_key_ct_label with a u32 array Jarno Rajahalme
2017-02-03  1:10 ` [PATCH net-next 3/7] openvswitch: Do not trigger events for unconfirmed connection Jarno Rajahalme
2017-02-06 21:46   ` Joe Stringer
2017-02-08  5:30     ` Jarno Rajahalme
2017-02-03  1:10 ` [PATCH net-next 4/7] openvswitch: Inherit master's labels Jarno Rajahalme
2017-02-06 21:53   ` Joe Stringer
2017-02-08  5:31     ` Jarno Rajahalme
2017-02-03  1:10 ` [PATCH net-next 5/7] openvswitch: Add original direction conntrack tuple to sw_flow_key Jarno Rajahalme
2017-02-07  7:15   ` Joe Stringer
2017-02-07 21:38     ` Joe Stringer
2017-02-08  5:31     ` Jarno Rajahalme
2017-02-03  1:10 ` [PATCH net-next 6/7] openvswitch: Add force commit Jarno Rajahalme
2017-02-06 17:08   ` Pravin Shelar
2017-02-07  7:28     ` Joe Stringer
2017-02-07 17:14       ` Pravin Shelar
2017-02-07 22:15   ` Joe Stringer
     [not found]     ` <5B795D0B-4C7F-4297-BA2A-6BE3444033D0@ovn.org>
2017-02-08  1:32       ` Joe Stringer
2017-02-08  5:31     ` Jarno Rajahalme
2017-02-03  1:10 ` [PATCH net-next 7/7] openvswitch: Pack struct sw_flow_key Jarno Rajahalme
2017-02-07  7:15   ` Joe Stringer
2017-02-08  1:11     ` Jarno Rajahalme
2017-02-08  5:31     ` Jarno Rajahalme
2017-02-05 22:28 ` [PATCH net-next 1/7] openvswitch: Use inverted tuple in ovs_ct_find_existing() if NATted David Miller
2017-02-06 17:06   ` Pravin Shelar
2017-02-06 17:15     ` David Miller
2017-02-07 17:14       ` Pravin Shelar [this message]
2017-02-07 21:29         ` Jarno Rajahalme
2017-02-07  0:45   ` Joe Stringer
2017-02-06 17:07 ` Pravin Shelar
2017-02-08  5:30   ` Jarno Rajahalme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOrHB_AOYrzDVZBST-TDZo2ZtrBqQiv6+0eHNDJuukGUDYGZFQ@mail.gmail.com \
    --to=pshelar@ovn.org \
    --cc=davem@davemloft.net \
    --cc=jarno@ovn.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.