1. 22 Mar, 2016 2 commits
  2. 25 Mar, 2016 1 commit
    • Daniele Di Proietto's avatar
      ovs-thread: Do not always end quiescent state in ovs_thread_create(). · 88b567e6
      Daniele Di Proietto authored
      A new thread must be started in a non quiescent state.  There is a call
      to ovsrcu_quiesce_end() in ovsthread_wrapper(), to enforce this.
      ovs_thread_create(), instead, is executed in the parent thread. It must
      call ovsrcu_quiesce_end() on its first invocation, to put the main
      thread in a non quiescent state.  On every other invocation, it doesn't
      make sense to alter the calling thread state, so this commits wraps the
      call to ovsrcu_quiesce_end() in an ovsthread_once construct.
      This fixes a bug in ovs-rcu where the first call in the process to
      ovsrcu_quiesce_start() will not be honored, because the calling thread
      will need to create the 'urcu' thread (and creating a thread will
      wrongly end its quiescent state).
          if (ovsthread_once_start(&once)) {
              ovs_thread_create("urcu") /*This will end the quiescent state*/
      This bug affects in particular ovs-vswitchd with DPDK.
      In the DPDK case the first threads created are "vhost_thread" and
      "dpdk_watchdog".  If dpdk_watchdog is the first to call
      ovsrcu_quiesce_start() (via xsleep()), the call is not honored and
      the RCU grace period lasts at least for DPDK_PORT_WATCHDOG_INTERVAL
      (5s on current master).  If vhost_thread, on the other hand, is the
      first to call ovsrcu_quiesce_start(), the call is not honored and the
      RCU grace period lasts undefinitely, because no more calls to
      ovsrcu_quiesce_start() are issued from vhost_thread.
      For some reason (it's a race condition after all), on current master,
      dpdk_watchdog will always be the first to call ovsrcu_quiesce_start(),
      but with the upcoming DPDK database configuration changes, sometimes
      vhost_thread will issue the first call to ovsrcu_quiesce_start().
      Sample ovs-vswitchd.log:
      2016-03-23T22:34:28.532Z|00004|ovs_rcu(urcu3)|WARN|blocked 8000 ms
      waiting for vhost_thread2 to quiesce
      2016-03-23T22:34:30.501Z|00118|ovs_rcu|WARN|blocked 8000 ms waiting for
      vhost_thread2 to quiesce
      2016-03-23T22:34:36.532Z|00005|ovs_rcu(urcu3)|WARN|blocked 16000 ms
      waiting for vhost_thread2 to quiesce
      2016-03-23T22:34:38.501Z|00119|ovs_rcu|WARN|blocked 16000 ms waiting for
      vhost_thread2 to quiesce
      The commit also adds a test for the ovs-rcu module to make sure that:
      * A new thread is started in a non quiescent state.
      * The first call to ovsrcu_quiesce_start() is honored.
      * When a process becomes multithreaded the main thread is put in an
        active state
      Signed-off-by: default avatarDaniele Di Proietto <diproiettod@vmware.com>
      Acked-by: default avatarBen Pfaff <blp@ovn.org>
  3. 22 Mar, 2016 1 commit
    • Ian Stokes's avatar
      bridge: Fix qos_unixctl_show bug. · 2f22d6a2
      Ian Stokes authored
      netdev_get_qos returns a value to indicate if an error has occurred while
      attempting to query the QoS configuration of an interface. If an error does
      occur the pointer argument passed to it will be set to null before returning.
      Currently the vswitch will segfault if this occurs as qos_unixctl_show will
      attempt to access the pointer directly after it calls netdev_get_qos.
      Avoid this by adding a check for the return value and flagging an appropriate
      error message to appctl.
      Signed-off-by: default avatarIan Stokes <ian.stokes@intel.com>
      [blp@ovn.org changed details of error report]
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
  4. 17 Mar, 2016 1 commit
  5. 03 Mar, 2016 2 commits
    • Joe Stringer's avatar
      ofp-actions: Prevent integer overflow in decode. · ad0099ef
      Joe Stringer authored
      Upstream commit 5308056f.
      When decoding a variable-length action, if the length of the action
      exceeds the length storable in a uint16_t then something has gone
      terribly wrong. Assert that this is not the case.
      Signed-off-by: default avatarJoe Stringer <joe@ovn.org>
      Acked-by: default avatarJarno Rajahalme <jarno@ovn.org>
    • Joe Stringer's avatar
      ofp-actions: Fix use-after-free in bundle action. · 8d24418b
      Joe Stringer authored
      Upstream commit 19b58f3c.
      If the actions list in an incoming flow mod is long enough, and there is
      a bundle() action with 3 or more slaves, then it is possible for a
      reallocation to occur after placing the ofpact_bundle into the ofpacts
      buffer, while slave ports into the buffer. If the memory freed by this
      reallocation is then passed to another thread, then that thread may
      modify the value that bundle->n_slaves points to. If this occurs quickly
      enough before the main thread finishes copying all of the slaves, then
      the iteration may continue beyond the originally intended number of
      slaves, copying (and swapping) an undetermined number of 2-byte chunks
      from the openflow message. Finally, the length of the ofpact will be
      updated based on how much data was written to the buffer, which may be
      significantly longer than intended.
      In many cases, the freed memory may not be allocated to another thread
      and be left untouched. In some milder bug cases, this will lead to
      'bundle' actions using more memory than required. In more serious cases,
      this length may then exceed the maximum length of an OpenFlow action,
      which is then stored (truncated) into the 16-bit length field in the
      ofpact header. Later execution of ofpacts_verify() would then use this
      length to iterate through the ofpacts, and may dereference memory in
      unintended ways, causing crashes or infinite loops by attempting to
      parse/validate arbitrary data as ofpact objects.
      Fix the issue by updating 'bundle' within the iteration, immediately
      after (potentially) expanding the bundle.
      Thanks to Jarno Rajahalme for his keen pair of eyes on finding this
      VMWare-BZ: #1614715
      Fixes: f25d0cf3 ("Introduce ofpacts, an abstraction of OpenFlow actions.")
      Signed-off-by: default avatarJoe Stringer <joe@ovn.org>
      Acked-by: default avatarJarno Rajahalme <jarno@ovn.org>
  6. 16 Feb, 2016 2 commits
  7. 06 Feb, 2016 5 commits
  8. 05 Feb, 2016 1 commit
  9. 04 Feb, 2016 1 commit
  10. 29 Jan, 2016 1 commit
  11. 11 Jan, 2016 1 commit
  12. 05 Jan, 2016 1 commit
  13. 04 Jan, 2016 1 commit
  14. 23 Dec, 2015 2 commits
  15. 22 Dec, 2015 1 commit
  16. 21 Dec, 2015 1 commit
  17. 20 Dec, 2015 1 commit
  18. 15 Dec, 2015 1 commit
  19. 11 Dec, 2015 1 commit
  20. 08 Dec, 2015 1 commit
  21. 04 Dec, 2015 1 commit
  22. 02 Dec, 2015 1 commit
    • Gurucharan Shetty's avatar
      debian: Skip systemctl redirect. · a7b0cebc
      Gurucharan Shetty authored
      After some experimentation on Ubuntu15.04, I see the
      following behavior.
      1. If you install openvswitch-switch with 'apt-get install',
      then you automatically get a upstart and systemd config files
      for openvswitch. The integration with 'interfaces' fails
      because both the upstart and systemd jobs do not have logic
      to handle it.
      The above behavior will likely get fixed soon in upstream
      2. If you install openvswitch-switch via the packages
      created from the openvswitch repo, there is no systemd or
      upstart conf files installed. But systemd notices this
      and creates a runtime openvswitch conf file which does
      nothing but call back the sysv startup script.
      In the above case when you call
      "/etc/init.d/openvswitch-switch start", it inturn calls
      "/bin/systemctl start openvswitch-switch.service" and
      that inturn again calls "/etc/init.d/openvswitch-switch start".
      But the above for some reason simply hangs. It looks like a call
      to ifup when invoked in this manner does not return.
      I am not sure why this is happening.
      We can avoid the above behavior completely by skipping the
      systemctl redirect as done in this commit. This should fix
      both 1. and 2. above.
      Signed-off-by: default avatarGurucharan Shetty <guru@ovn.org>
      Acked-by: default avatarBen Pfaff <blp@ovn.org>
  23. 29 Nov, 2015 1 commit
  24. 10 Nov, 2015 1 commit
  25. 03 Nov, 2015 1 commit
  26. 30 Oct, 2015 1 commit
  27. 29 Oct, 2015 1 commit
  28. 24 Oct, 2015 1 commit
  29. 16 Oct, 2015 1 commit
  30. 09 Oct, 2015 1 commit
    • Pravin B Shelar's avatar
      datapath: Fix compilation on kernel 2.6.32 · f922763a
      Pravin B Shelar authored
      Fixes following compilation error:
      CC [M]  /home/travis/build/openvswitch/ovs/datapath/linux/actions.o
      In file included from
      In function ‘rpl_skb_postpull_rcsum’:
      error: implicit declaration of function ‘skb_checksum_start_offset’
      cc1: some warnings being treated as errors
      Reported-by: default avatarJoe Stringer <joestringer@nicira.com>
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Acked-by: default avatarJoe Stringer <joestringer@nicira.com>
  31. 26 Sep, 2015 2 commits
    • Pravin B Shelar's avatar
      datapath: Fix datapath compilation error. · 35fd3364
      Pravin B Shelar authored
        CC [M]  /home/pravin/ovs/cln/datapath/linux/flow_table.o
      datapath/linux/flow_table.c: In function ‘masked_flow_lookup’:
      datapath/linux/flow_table.c:508:2: warning: passing argument 2 of ‘flow_hash’ makes integer from pointer without a cast
      [enabled by default]
        hash = flow_hash(&masked_key, &mask->range);
      datapath/linux/flow_table.c:442:12: note: expected ‘int’ but argument is of type ‘struct sw_flow_key_range *’
       static u32 flow_hash(const struct sw_flow_key *key, int key_start,
      datapath/linux/flow_table.c:508:2: error: too few arguments to function ‘flow_hash’
        hash = flow_hash(&masked_key, &mask->range);
      datapath/linux/flow_table.c:442:12: note: declared here
       static u32 flow_hash(const struct sw_flow_key *key, int key_start,
      make[5]: *** [/home/pravin/ovs/cln/datapath/linux/flow_table.o] Error 1
      Fixes: bd42c105 ("datapath: Backport "openvswitch: Zero flows on
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
    • Pravin B Shelar's avatar
      datapath: Backport "skbuff: Fix skb checksum flag on skb pull" · 51b7a902
      Pravin B Shelar authored
      Upstream commit:
          VXLAN device can receive skb with checksum partial. But the checksum
          offset could be in outer header which is pulled on receive. This results
          in negative checksum offset for the skb. Such skb can cause the assert
          failure in skb_checksum_help(). Following patch fixes the bug by setting
          checksum-none while pulling outer header.
          Following is the kernel panic msg from old kernel hitting the bug.
          ------------[ cut here ]------------
          kernel BUG at net/core/dev.c:1906!
          RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150
          Call Trace:
          [<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch]
          [<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch]
          [<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
          [<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
          [<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch]
          [<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch]
          [<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
          [<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0
          [<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0
          [<ffffffff8157ba7a>] udp_rcv+0x1a/0x20
          [<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280
          [<ffffffff81550128>] ip_local_deliver+0x88/0x90
          [<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370
          [<ffffffff81550365>] ip_rcv+0x235/0x300
          [<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620
          [<ffffffff8151c360>] netif_receive_skb+0x80/0x90
          [<ffffffff81459935>] virtnet_poll+0x555/0x6f0
          [<ffffffff8151cd04>] net_rx_action+0x134/0x290
          [<ffffffff810683d8>] __do_softirq+0xa8/0x210
          [<ffffffff8162fe6c>] call_softirq+0x1c/0x30
          [<ffffffff810161a5>] do_softirq+0x65/0xa0
          [<ffffffff810687be>] irq_exit+0x8e/0xb0
          [<ffffffff81630733>] do_IRQ+0x63/0xe0
          [<ffffffff81625f2e>] common_interrupt+0x6e/0x6e
      Reported-by: default avatarAnupam Chanda <achanda@vmware.com>
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Acked-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Upstream: 6ae459bdaae ("skbuff: Fix skb checksum flag on skb pull")
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Acked-by: default avatarJesse Gross <jesse@nicira.com>