1. 26 Feb, 2018 1 commit
  2. 16 Feb, 2018 1 commit
  3. 06 Feb, 2018 1 commit
  4. 26 Jan, 2018 4 commits
    • Ian Stokes's avatar
      netdev-dpdk: Fix requested MTU size validation. · eee9eec3
      Ian Stokes authored
      This commit replaces MTU_TO_FRAME_LEN(mtu) with MTU_TO_MAX_FRAME_LEN(mtu)
      in netdev_dpdk_set_mtu(), in order to determine if the total length of
      the L2 frame with an MTU of ’mtu’ exceeds NETDEV_DPDK_MAX_PKT_LEN.
      When setting an MTU we first check if the requested total frame length
      (which includes associated L2 overhead) will exceed the maximum
      frame length supported in netdev_dpdk_set_mtu(). The frame length is
      calculated by MTU_TO_FRAME_LEN  as MTU + ETHER_HEADER + ETHER_CRC. The MTU
      for the device will be set at a later stage in dpdk_eth_dev_init() using
      However when using rte_eth_dev_set_mtu(mtu) the calculation used to check
      that the frame does not exceed the max frame length for that device varies
      between DPDK device drivers. For example ixgbe driver calculates the
      frame length for a given MTU as
      i40e driver calculates it as
      em driver calculates it as
      Currently it is possible to set an MTU for a netdev_dpdk device that exceeds
      the upper limit MTU for that devices DPDK driver. This leads to a segfault.
      This is because the frame length comparison as is, does not take into account
      the addition of the vlan tag overhead expected in the drivers. The
      netdev_dpdk_set_mtu() call will incorrectly succeed but the subsequent
      dpdk_eth_dev_init() will fail before the queues have been created for the
      DPDK device. This coupled with assumptions regarding reconfiguration
      requirements for the netdev will lead to a segfault when the rxq is polled
      for this device.
      A simple way to avoid this is by using MTU_TO_MAX_FRAME_LEN(mtu) when
      validating a requested MTU in netdev_dpdk_set_mtu().
      MTU_TO_MAX_FRAME_LEN(mtu) is equivalent to the following:
      By using MTU_TO_MAX_FRAME_LEN at the netdev_dpdk_set_mtu() stage, OvS
      now takes into account the maximum L2 overhead that a DPDK driver could
      allow for in its frame size calculation. This allows OVS to flag an error
      rather than the DPDK driver if the frame length exceeds the max DPDK frame
      length. OVS can fail gracefully at this point and use the default MTU of
      1500 to continue to configure the port.
      Note: this fix is a work around, a better approach would be if DPDK devices
      could report the maximum MTU value that can be requested on a per device
      basis. This capability however is not currently available. A downside of
      this patch is that the MTU upper limit will be reduced by 8 bytes for
      DPDK devices that do not need to account for vlan tags in the frame length
      driver calculations e.g. ixgbe devices upper MTU limit is reduced from
      the OVS point of view from 9710 to 9702.
      CC: Mark Kavanagh <mark.b.kavanagh@intel.com>
      Fixes: 0072e931 ("netdev-dpdk: add support for jumbo frames")
      Signed-off-by: default avatarIan Stokes <ian.stokes@intel.com>
      Co-authored-by: default avatarMark Kavanagh <mark.b.kavanagh@intel.com>
      Signed-off-by: default avatarMark Kavanagh <mark.b.kavanagh@intel.com>
      Acked-by: default avatarFlavio Leitner <fbl@sysclose.org>
    • zhangliping's avatar
      netdev-dpdk: fix ingress_policer leak on error path · 63d845a9
      zhangliping authored
      Fix memory leak by freeing the policer if rte_meter_srtcm_config fails.
      Fixes: 9509913a ("netdev-dpdk.c: Add ingress-policing functionality.")
      Signed-off-by: default avatarzhangliping <zhangliping02@baidu.com>
      Signed-off-by: default avatarIan Stokes <ian.stokes@intel.com>
    • Ben Pfaff's avatar
      ofproto: Fix double-unref of temporary rule when learning. · 8add6d8c
      Ben Pfaff authored
      When ofproto_flow_mod_init() accepts a rule, it takes ownership of it and
      either unrefs it on error or transfers ownership to the struct it
      initializes on success, but ofproto_flow_mod_init_for_learn() was unref-ing
      it a second time if it reported an error.
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
      Acked-by: default avatarWilliam Tu <u9012063@gmail.com>
    • wenxu's avatar
      gre: strip gre-tso offload flags · c069da15
      wenxu authored
      if the gro enable, ipgre receive a gre-tso package. After pop
      the gre-tunnel the encapsulation and GSO_ENCAP flags should be
      striped. or the packet encap again and will be dropped in
      Signed-off-by: default avatarwenxu <wenxu@ucloud.cn>
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
      Tested-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
  5. 12 Jan, 2018 1 commit
  6. 09 Jan, 2018 3 commits
  7. 08 Jan, 2018 1 commit
  8. 22 Dec, 2017 2 commits
  9. 20 Dec, 2017 1 commit
    • Yifeng Sun's avatar
      bond: Fix bug that writes to freed memory · 0e5cd169
      Yifeng Sun authored
      pr_op->pr_rule is pointing to memory in bond->hash. It shouldn't be written
      if bond->hash is already freed.
      This bug is reported by running kernel path testsuite under valgrind:
      Invalid write of size 8
         at 0x413D16: update_recirc_rules__ (bond.c:392)
         by 0x414CA0: bond_unref (bond.c:290)
         by 0x427E3C: bundle_destroy (ofproto-dpif.c:3002)
         by 0x429EF4: bundle_set (ofproto-dpif.c:3023)
         by 0x40858B: port_destroy (bridge.c:4087)
         by 0x40BD04: bridge_destroy (bridge.c:3266)
         by 0x410528: bridge_exit (bridge.c:506)
         by 0x4072EE: main (ovs-vswitchd.c:135)
       Address 0xb5a85f0 is 5,360 bytes inside a block of size 12,288 free'd
         at 0x4C2EDEB: free (/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
         by 0x414C8D: bond_unref (bond.c:288)
         by 0x427E3C: bundle_destroy (ofproto-dpif.c:3002)
         by 0x429EF4: bundle_set (ofproto-dpif.c:3023)
         by 0x40858B: port_destroy (bridge.c:4087)
         by 0x40BD04: bridge_destroy (bridge.c:3266)
         by 0x410528: bridge_exit (bridge.c:506)
         by 0x4072EE: main (ovs-vswitchd.c:135)
       Block was alloc'd at
         at 0x4C2DB8F: malloc (/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
         by 0x516C04: xmalloc (util.c:120)
         by 0x414FD1: bond_entry_reset (bond.c:1651)
         by 0x414FD1: bond_reconfigure (bond.c:470)
         by 0x41507D: bond_create (bond.c:245)
         by 0x429D5D: bundle_set (ofproto-dpif.c:3194)
         by 0x408AC8: port_configure (bridge.c:1052)
         by 0x40CD87: bridge_reconfigure (bridge.c:682)
         by 0x410775: bridge_run (bridge.c:2998)
         by 0x407244: main (ovs-vswitchd.c:119)
      Signed-off-by: default avatarYifeng Sun <pkusunyifeng@gmail.com>
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
      Tested-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
  10. 12 Dec, 2017 1 commit
  11. 11 Dec, 2017 2 commits
  12. 06 Dec, 2017 2 commits
  13. 05 Dec, 2017 1 commit
    • Numan Siddique's avatar
      OVN pacemaker: Add the monitor action for Master role · e7b9b17c
      Numan Siddique authored
      Pacemaker Resource agent periodically calls the OVN OCF's "monitor" action
      periodically to check the status. But the OVN OCF script doesn't add the
      action "monitor" for the role "Master" because of which the pacemaker
      resource agent do not call the "monitor" action at all for the master.
      In case OVN db servers exit for some reason this totally gets undetected
      and one of the standby node is not promoted to master.
      This patch adds the monitor action for "Master" role. Also the monitor
      action do not check for the status of the ovn-northd (if manage_northd is yes).
      This patch also checks for the status of the ovn-northd in the monitor action
      for the "Master" role. If any of the ovsdb-server or ovn-northd is not running,
      monitor action will return OCF_NOT_RUNNING and this will cause the pacemaker
      to restart the OVN OCF resource.
      Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1512568Signed-off-by: default avatarNuman Siddique <nusiddiq@redhat.com>
      CC: Russell Bryant <russell@ovn.org>
      Signed-off-by: default avatarRussell Bryant <russell@ovn.org>
  14. 04 Dec, 2017 1 commit
    • Yunjian Wang's avatar
      datapath: Fix kernel panic for uninitialized tun_dst of ovs_gso_cb. · 43afe13e
      Yunjian Wang authored
      The variable tun_dst in struct ovs_gso_cb isn't necessarily all-zeros which
      came from the Netlink layer. When delete a netdev port and immediately add
      a vxlan port, they maybe use the same port_no. So the variable tun_dst of
      struct ovs_gso_cb hasn't be set, when the skb sent to the vxlan port. And
      the panic will be triggered.
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000052
      	IP: [<ffffffffa07954f4>] rpl_vxlan_xmit+0x34/0x60 [openvswitch]
      	PGD 1f9f374067 PUD 1f9f375067 PMD 0
      	Oops: 0000 [#1] SMP
      	RIP: 0010:[<ffffffffa07954f4>]  [<ffffffffa07954f4>] rpl_vxlan_xmit+0x34/0x60 [openvswitch]
      	RSP: 0018:ffff881fff483898  EFLAGS: 00010202
      	RAX: 0000000000000040 RBX: ffff881ff2d59f00 RCX: ffff881f742016b0
      	RDX: 0000000000000001 RSI: ffff881f9f5f0000 RDI: ffff881ff2d59f00
      	RBP: ffff881fff483898 R08: 000000000000002e R09: 0000000000000000
      	R10: 0000000000000000 R11: ffff881fff483a50 R12: ffff881f74201680
      	R13: 000000000000ffbe R14: 0000000000000000 R15: ffff881ff2d59f00
      	FS:  00007f8b6f7fe700(0000) GS:ffff881fff480000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 0000000000000052 CR3: 0000001f9f373000 CR4: 00000000000027e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	Call Trace:
      	[<ffffffffa0786480>] ovs_vport_send+0xa0/0x180 [openvswitch]
      	[<ffffffffa077414e>] do_output+0x4e/0xf0 [openvswitch]
      	[<ffffffffa07758ae>] do_execute_actions+0xa6e/0xa90 [openvswitch]
      	[<ffffffff815b654f>] ? netlink_unicast+0x16f/0x1b0
      	[<ffffffff815732bb>] ? skb_zerocopy+0x1fb/0x380
      	[<ffffffffa07847ca>] ? flow_lookup.isra.8+0x4a/0xc0 [openvswitch]
      	[<ffffffffa0775b2d>] ovs_execute_actions+0x4d/0x140 [openvswitch]
      	[<ffffffffa077c604>] ovs_dp_process_packet+0x94/0x140 [openvswitch]
      	[<ffffffffa07762c4>] ? ovs_ct_update_key+0xc4/0x150 [openvswitch]
      	[<ffffffffa078637b>] ovs_vport_receive+0x7b/0xe0 [openvswitch]
      	[<ffffffffa077c604>] ? ovs_dp_process_packet+0x94/0x140 [openvswitch]
      	[<ffffffff816062d6>] ? __fib_validate_source.isra.13+0x2b6/0x400
      	[<ffffffff8158da15>] ? dst_init+0xe5/0xf0
      	[<ffffffffa021a2af>] ? generic_packet+0x1f/0x30 [nf_conntrack]
      	[<ffffffffa02160d0>] ? nf_conntrack_in+0x350/0x5f0 [nf_conntrack]
      	[<ffffffffa0787047>] netdev_port_receive+0xa7/0x100 [openvswitch]
      	[<ffffffffa07870be>] netdev_frame_hook+0x1e/0x30 [openvswitch]
      	[<ffffffff81581a52>] __netif_receive_skb_core+0x1e2/0x800
      	[<ffffffff81582088>] __netif_receive_skb+0x18/0x60
      	[<ffffffff81582110>] netif_receive_skb_internal+0x40/0xc0
      	[<ffffffff81583228>] napi_gro_receive+0xd8/0x130
      	[<ffffffffa04ef634>] ixgbe_clean_rx_irq+0x7c4/0xa60 [ixgbe]
      	[<ffffffffa04f0930>] ixgbe_poll+0x2e0/0x6c0 [ixgbe]
      	[<ffffffff815828b0>] net_rx_action+0x170/0x380
      	[<ffffffff81090b0f>] __do_softirq+0xef/0x280
      	[<ffffffff816ac15c>] call_softirq+0x1c/0x30
      	[<ffffffff8102e47d>] do_softirq+0x5d/0xb0
      	[<ffffffff81090ebd>] irq_exit+0x12d/0x140
      	[<ffffffff816accf8>] do_IRQ+0x58/0xf0
      	[<ffffffff816a1ced>] common_interrupt+0x6d/0x6d
      Signed-off-by: default avatarYunjian Wang <wangyunjian@huawei.com>
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
      Tested-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
  15. 30 Nov, 2017 2 commits
  16. 29 Nov, 2017 2 commits
    • Yifeng Sun's avatar
      dpif: Fix memory leak · cf99f8ff
      Yifeng Sun authored
      Valgrind complains in test 2322 (ovn -- 3 HVs, 3 LS, 3 lports/LS, 1 LR):
      31,584 (26,496 direct, 5,088 indirect) bytes in 48 blocks are definitely
      lost in loss record 422 of 427
         by 0x5165F4: xmalloc (util.c:120)
         by 0x466194: dp_packet_new (dp-packet.c:138)
         by 0x466194: dp_packet_new_with_headroom (dp-packet.c:148)
         by 0x46621B: dp_packet_clone_data_with_headroom (dp-packet.c:210)
         by 0x46621B: dp_packet_clone_with_headroom (dp-packet.c:170)
         by 0x49DD46: dp_packet_batch_clone (dp-packet.h:789)
         by 0x49DD46: odp_execute_clone (odp-execute.c:616)
         by 0x49DD46: odp_execute_actions (odp-execute.c:795)
         by 0x471663: dpif_execute_with_help (dpif.c:1296)
         by 0x473795: dpif_operate (dpif.c:1411)
         by 0x473E20: dpif_execute.part.21 (dpif.c:1320)
         by 0x428D38: packet_execute (ofproto-dpif.c:4682)
         by 0x41EB51: ofproto_packet_out_finish (ofproto.c:3540)
         by 0x41EB51: handle_packet_out (ofproto.c:3581)
         by 0x4233DA: handle_openflow__ (ofproto.c:8044)
         by 0x4233DA: handle_openflow (ofproto.c:8219)
         by 0x4514AA: ofconn_run (connmgr.c:1437)
         by 0x4514AA: connmgr_run (connmgr.c:363)
         by 0x41C8B5: ofproto_run (ofproto.c:1813)
         by 0x40B103: bridge_run__ (bridge.c:2919)
         by 0x4103B3: bridge_run (bridge.c:2977)
         by 0x406F14: main (ovs-vswitchd.c:119)
      the parameter dp_packet_batch is leaked when 'may_steal' is true.
      When dpif_execute_helper_cb is passed with a true 'may_steal', it
      is supposed to take the ownership of dp_packet_batch and release
      it when done.
      Signed-off-by: default avatarYifeng Sun <pkusunyifeng@gmail.com>
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
    • Lili Huang's avatar
      ovs-ofctl: Fix bad free in colors_parse_from_env(). · 49fa53b9
      Lili Huang authored
      OVS_COLORS variable color_str is parsed by using xstrdup and strsep,
      we should free original address of the string, not used after strsep.
      Signed-off-by: default avatarLili Huang <huanglili.huang@huawei.com>
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
      Acked-by: default avatarMark Michelson <mmichels@redhat.com>
  17. 28 Nov, 2017 2 commits
  18. 27 Nov, 2017 6 commits
  19. 14 Nov, 2017 1 commit
  20. 13 Nov, 2017 1 commit
  21. 02 Nov, 2017 2 commits
  22. 01 Nov, 2017 1 commit
  23. 31 Oct, 2017 1 commit