1. 27 Feb, 2016 1 commit
  2. 26 Feb, 2016 1 commit
    • Ansis Atteka's avatar
      rhel: provide our own SELinux custom policy package · bb3af1bf
      Ansis Atteka authored
      CentOS, RHEL and Fedora distributions ship with their own Open vSwitch
      SELinux policy that is too strict and prevents Open vSwitch to work
      normally out of the box.
      
      As a solution, this patch introduces a new package which will "loosen"
      up "openvswitch_t" SELinux domain so that Open vSwitch could operate
      normally.
      
      Intended use-cases of this package are:
      1. to allow users to install newer Open vSwitch on already released Fedora,
      RHEL and CentOS distributions where the default Open vSwitch SELinux policy
      that shipped with the corresponding Linux distribution is not up to date
      and did not anticipate that a newer Open vSwitch version might need to
      invoke new system calls or need to access certain system resources that
      it did not before; And
      2. to provide alternative means through which Open vSwitch developers
      can proactively fix SELinux related policy issues without waiting for
      corresponding Linux distribution maintainers to update their central
      Open vSwitch SELinux policy.
      
      This patch was tested on Fedora 23 and CentOS 7. I verified that now
      on Fedora 23 Open vSwitch can create a NetLink socket; and that I did
      not see following error messages:
      
      vlog|INFO|opened log file /var/log/openvswitch/ovs-vswitchd.log
      ovs_numa|INFO|Discovered 2 CPU cores on NUMA node 0
      ovs_numa|INFO|Discovered 1 NUMA nodes and 2 CPU cores
      reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting...
      reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected
      netlink_socket|ERR|fcntl: Permission denied
      dpif_netlink|ERR|Generic Netlink family 'ovs_datapath' does not exist.
                       The Open vSwitch kernel module is p robably not loaded.
      dpif|WARN|failed to enumerate system datapaths: Permission denied
      dpif|WARN|failed to create datapath ovs-system: Permission denied
      
      I did not test all Open vSwitch features so there still could be some
      OVS configuration that would get "Permission denied" errors.
      
      Since, Open vSwitch daemons on Ubuntu 15.10 by default run under "unconfined"
      SELinux domain, then there is no need to create a similar debian package
      for Ubuntu, because it works on default Ubuntu installation.
      Signed-off-by: default avatarAnsis Atteka <aatteka@nicira.com>
      Acked-by: default avatarFlavio Leitner <fbl@sysclose.com>
      bb3af1bf
  3. 25 Feb, 2016 3 commits
  4. 24 Feb, 2016 3 commits
  5. 23 Feb, 2016 4 commits
  6. 19 Feb, 2016 10 commits
  7. 18 Feb, 2016 1 commit
  8. 16 Feb, 2016 2 commits
  9. 06 Feb, 2016 3 commits
  10. 05 Feb, 2016 3 commits
  11. 04 Feb, 2016 7 commits
  12. 03 Feb, 2016 2 commits
    • Ben Pfaff's avatar
      ofproto: Detect and handle errors in ofproto_port_add(). · 6108ead1
      Ben Pfaff authored
      The update_port() function called in ofproto_port_add() can encounter
      errors that prevent a port from being added, but nothing was checking for
      the error and in fact update_port() didn't even pass the error along to
      its caller.  This commit fixes the problem.
      
      The scenario that led me to examine this code can be triggered as follows
      from the sandbox, as long as you change --enable-dummy=override to
      --enable-dummy=system in ovs-sandbox:
      
      ovs-vsctl add-br br0
      ovs-vsctl add-port br0 tun0 \
          -- set interface tun0 type=stt options:remote_ip=1.2.3.4
      ovs-vsctl add-port br0 tun1 \
          -- set interface tun1 type=stt options:remote_ip=1.2.3.4
      
      The second add-port will fail due to the duplicate tunnel options, but
      ofproto_port_add() will not return the error.  Instead, it will report to
      the caller that it succeeded and tell it that it has ofp_port OFPP_NONE
      (65535), which is invalid and it obviously does not.  The result is that
      you get bizarre log messages like this:
      
          tunnel|WARN|tun1: attempting to add tunnel port with same config as port 'tun0' (::->1.2.3.4, key=0, dp port=7471, pkt mark=0)
          ofproto|WARN|br0: could not add port tun1 (File exists)
          bridge|INFO|bridge br0: added interface tun1 on port 65535
          ofproto|WARN|br0: cannot configure bfd on nonexistent port 65535
          ofproto|WARN|br0: cannot configure LLDP on nonexistent port 65535
          ofproto|WARN|br0: cannot get STP status on nonexistent port 65535
          ofproto|WARN|br0: cannot get RSTP status on nonexistent port 65535
          ofproto|WARN|br0: cannot get STP stats on nonexistent port 65535
          ofproto|WARN|br0: cannot get STP stats on nonexistent port 65535
      
      VMware-BZ: #1598643
      Signed-off-by: default avatarBen Pfaff <blp@ovn.org>
      Acked-by: default avatarJustin Pettit <jpettit@ovn.org>
      6108ead1
    • Daniele Di Proietto's avatar
      dpif-netdev: Fix improper use of CMAP_FOR_EACH. · c0e32758
      Daniele Di Proietto authored
      It is ok to iterate a cmap with CMAP_FOR_EACH and remove elements with
      cmap_remove(), but having quiescent states inside the loop might create
      problems, since some of the postponed cleanup done inside the cmap might
      be executed, freeing the memory that the iterator is using.
      
      We had several of these errors in dpif-netdev, because when we rearrange
      ports or threads we often need to wait on a condition variable (which
      implies a quiescent state).
      
      This problem caused iterations to skip elements or to list them twice,
      resulting in the main thread waiting on a condition without anyone else
      to signal.
      
      Fix these cases by moving the possible quiescent states outside
      CMAP_FOR_EACH loops.
      Signed-off-by: default avatarDaniele Di Proietto <diproiettod@vmware.com>
      Tested-by: default avatarIlya Maximets <i.maximets@samsung.com>
      Acked-by: default avatarIlya Maximets <i.maximets@samsung.com>
      Acked-by: default avatarJarno Rajahalme <jarno@ovn.org>
      c0e32758