1. 23 3月, 2017 1 次提交
  2. 03 3月, 2017 1 次提交
  3. 10 2月, 2017 1 次提交
    • J
      openvswitch: Add original direction conntrack tuple to sw_flow_key. · 9dd7f890
      Jarno Rajahalme 提交于
      Add the fields of the conntrack original direction 5-tuple to struct
      sw_flow_key.  The new fields are initially marked as non-existent, and
      are populated whenever a conntrack action is executed and either finds
      or generates a conntrack entry.  This means that these fields exist
      for all packets that were not rejected by conntrack as untrackable.
      
      The original tuple fields in the sw_flow_key are filled from the
      original direction tuple of the conntrack entry relating to the
      current packet, or from the original direction tuple of the master
      conntrack entry, if the current conntrack entry has a master.
      Generally, expected connections of connections having an assigned
      helper (e.g., FTP), have a master conntrack entry.
      
      The main purpose of the new conntrack original tuple fields is to
      allow matching on them for policy decision purposes, with the premise
      that the admissibility of tracked connections reply packets (as well
      as original direction packets), and both direction packets of any
      related connections may be based on ACL rules applying to the master
      connection's original direction 5-tuple.  This also makes it easier to
      make policy decisions when the actual packet headers might have been
      transformed by NAT, as the original direction 5-tuple represents the
      packet headers before any such transformation.
      
      When using the original direction 5-tuple the admissibility of return
      and/or related packets need not be based on the mere existence of a
      conntrack entry, allowing separation of admission policy from the
      established conntrack state.  While existence of a conntrack entry is
      required for admission of the return or related packets, policy
      changes can render connections that were initially admitted to be
      rejected or dropped afterwards.  If the admission of the return and
      related packets was based on mere conntrack state (e.g., connection
      being in an established state), a policy change that would make the
      connection rejected or dropped would need to find and delete all
      conntrack entries affected by such a change.  When using the original
      direction 5-tuple matching the affected conntrack entries can be
      allowed to time out instead, as the established state of the
      connection would not need to be the basis for packet admission any
      more.
      
      It should be noted that the directionality of related connections may
      be the same or different than that of the master connection, and
      neither the original direction 5-tuple nor the conntrack state bits
      carry this information.  If needed, the directionality of the master
      connection can be stored in master's conntrack mark or labels, which
      are automatically inherited by the expected related connections.
      
      The fact that neither ARP nor ND packets are trackable by conntrack
      allows mutual exclusion between ARP/ND and the new conntrack original
      tuple fields.  Hence, the IP addresses are overlaid in union with ARP
      and ND fields.  This allows the sw_flow_key to not grow much due to
      this patch, but it also means that we must be careful to never use the
      new key fields with ARP or ND packets.  ARP is easy to distinguish and
      keep mutually exclusive based on the ethernet type, but ND being an
      ICMPv6 protocol requires a bit more attention.
      Signed-off-by: NJarno Rajahalme <jarno@ovn.org>
      Acked-by: NJoe Stringer <joe@ovn.org>
      Acked-by: NPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9dd7f890
  4. 30 1月, 2017 1 次提交
  5. 13 11月, 2016 5 次提交
  6. 12 10月, 2016 1 次提交
  7. 03 10月, 2016 1 次提交
  8. 16 9月, 2016 1 次提交
  9. 09 9月, 2016 1 次提交
  10. 31 8月, 2016 1 次提交
    • D
      net: mpls: Fixups for GSO · 48d2ab60
      David Ahern 提交于
      As reported by Lennert the MPLS GSO code is failing to properly segment
      large packets. There are a couple of problems:
      
      1. the inner protocol is not set so the gso segment functions for inner
         protocol layers are not getting run, and
      
      2  MPLS labels for packets that use the "native" (non-OVS) MPLS code
         are not properly accounted for in mpls_gso_segment.
      
      The MPLS GSO code was added for OVS. It is re-using skb_mac_gso_segment
      to call the gso segment functions for the higher layer protocols. That
      means skb_mac_gso_segment is called twice -- once with the network
      protocol set to MPLS and again with the network protocol set to the
      inner protocol.
      
      This patch sets the inner skb protocol addressing item 1 above and sets
      the network_header and inner_network_header to mark where the MPLS labels
      start and end. The MPLS code in OVS is also updated to set the two
      network markers.
      
      >From there the MPLS GSO code uses the difference between the network
      header and the inner network header to know the size of the MPLS header
      that was pushed. It then pulls the MPLS header, resets the mac_len and
      protocol for the inner protocol and then calls skb_mac_gso_segment
      to segment the skb.
      
      Afterward the inner protocol segmentation is done the skb protocol
      is set to mpls for each segment and the network and mac headers
      restored.
      Reported-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48d2ab60
  11. 11 6月, 2016 1 次提交
  12. 01 6月, 2016 1 次提交
  13. 22 4月, 2016 1 次提交
  14. 20 2月, 2016 1 次提交
  15. 19 1月, 2016 1 次提交
    • H
      ovs: limit ovs recursions in ovs_execute_actions to not corrupt stack · b064d0d8
      Hannes Frederic Sowa 提交于
      It was seen that defective configurations of openvswitch could overwrite
      the STACK_END_MAGIC and cause a hard crash of the kernel because of too
      many recursions within ovs.
      
      This problem arises due to the high stack usage of openvswitch. The rest
      of the kernel is fine with the current limit of 10 (RECURSION_LIMIT).
      
      We use the already existing recursion counter in ovs_execute_actions to
      implement an upper bound of 5 recursions.
      
      Cc: Pravin Shelar <pshelar@ovn.org>
      Cc: Simon Horman <simon.horman@netronome.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Simon Horman <simon.horman@netronome.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b064d0d8
  16. 28 10月, 2015 1 次提交
  17. 23 10月, 2015 1 次提交
    • P
      openvswitch: Fix egress tunnel info. · fc4099f1
      Pravin B Shelar 提交于
      While transitioning to netdev based vport we broke OVS
      feature which allows user to retrieve tunnel packet egress
      information for lwtunnel devices.  Following patch fixes it
      by introducing ndo operation to get the tunnel egress info.
      Same ndo operation can be used for lwtunnel devices and compat
      ovs-tnl-vport devices. So after adding such device operation
      we can remove similar operation from ovs-vport.
      
      Fixes: 614732ea ("openvswitch: Use regular VXLAN net_device device").
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc4099f1
  18. 07 10月, 2015 2 次提交
  19. 05 10月, 2015 1 次提交
  20. 30 9月, 2015 5 次提交
  21. 01 9月, 2015 1 次提交
  22. 30 8月, 2015 1 次提交
  23. 28 8月, 2015 5 次提交
  24. 18 8月, 2015 1 次提交
  25. 08 8月, 2015 1 次提交
  26. 04 8月, 2015 1 次提交
  27. 22 7月, 2015 1 次提交