1. 17 Dec, 2015 14 commits
  2. 12 Dec, 2015 3 commits
  3. 11 Dec, 2015 1 commit
  4. 10 Dec, 2015 7 commits
  5. 09 Dec, 2015 4 commits
  6. 01 Dec, 2015 4 commits
  7. 27 Nov, 2015 7 commits
    • Thomas Haller's avatar
      platform: emit signals by signal-id instead of string · 832539a5
      Thomas Haller authored
      We potentially emit a lot of signals. Don't look up the
      signal by name because that adds quite some additional
      overhead, like peeking for a GQuark.
      
      Instead pass the numeric signal-id directly.
      832539a5
    • Thomas Haller's avatar
      platform: remove NMPlatformReason enum · 510e53ca
      Thomas Haller authored
      This enum was unused and meaningless because the platform signals
      are emitted as a consequence of netlink messages. It is not clear
      whether a netlink message was received due to an external event
      or an internal action.
      510e53ca
    • Thomas Haller's avatar
      platform: cope differently with spurious RTM_DELLINK message when unslaving bridge-slave · 8a87a918
      Thomas Haller authored
      Unslaving from a bridge causes a wrong RTM_DELLINK event for
      the former slave.
      
          # ip link add dummy0 type dummy
          # ip link add bridge0 type bridge
          # ip link set bridge0 up
          # ip link set dummy0 master bridge0
          # ip monitor link &
          # ip link set dummy0 nomaster
          18: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master bridge0 state DOWN group default
              link/ether 76:44:5f:b9:38:02 brd ff:ff:ff:ff:ff:ff
          18: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
              link/ether 76:44:5f:b9:38:02
          Deleted 18: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
              link/ether 76:44:5f:b9:38:02
          18: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
              link/ether 76:44:5f:b9:38:02 brd ff:ff:ff:ff:ff:ff
          19: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
              link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
          19: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
              link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
      
      Previously, during do_request_link() we would remember the link that is
      about to be requested (delayed_deletion) and delay processing a new
      RTM_DELLINK message until the end of do_request_link() -- and possibly
      forget about about the deletion, if RTM_DELLINK was followed by a
      RTM_NEWLINK.
      
      However, this hack does not catch the case where an external command
      unslaves the link.
      
      Instead just accept the wrong event and raise a "removed" signal right
      away. This brings the cache in an externally visible, wrong state that
      will be fixed by a following "added" signal.
      
      Still do that because working around the kernel bug is complicated. Also,
      we already might emit wrong "added" signals for devices that are already
      removed. As a consequence, a user should not consider the platform signals
      until all events are processed.
      Listeners to that signal should accept that added/removed link changes
      can be wrong and should preferably handle them idly, when the events
      have settled.
      
      It can even be worse, that a RTM_DELLINK is not fixed by a following
      RTM_NEWLINK:
      
          ...
          # ip link set dummy0 nomaster
          36: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master bridge0 state DOWN
              link/ether e2:f2:20:98:3a:be brd ff:ff:ff:ff:ff:ff
          36: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
              link/ether e2:f2:20:98:3a:be
          Deleted 36: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
              link/ether e2:f2:20:98:3a:be
          37: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
              link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
          37: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
              link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
      
      So, when a slave is deleted, we have to refetch it too.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1285719
      8a87a918
    • Thomas Haller's avatar
      Revert "platform: cancel delayed action REFRESH_LINK when receiving an update" · 83240f24
      Thomas Haller authored
      On some kernels (at least RHEL-7.2) we receive a spurious RTM_NEWLINK
      message after the RTM_DELLINK message for deleting a bond master.
      
      On RHEL-7, the following commands give:
      
          # ip link add dummy0 type dummy
          # ip link add bond0 type bond
          # ip link set bond0 up
          # ip link set dummy0 master bond0
          # ip monitor link &
          # ip link del bond0
          21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue state DOWN
              link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
          Deleted 21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
              link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
          20: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
              link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
          21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
              link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
      
          ^^^^^^^^^^^^^^^ RTM_NEWLINK after RTM_DELLINK (and there follows no
          RTM_DELLINK afterwards)
      
          21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
              link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
          20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
              link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
          20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
              link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
      
      Fix that by reverting clear_REFRESH_LINK(). This fix has two downsides:
      
      - on kernels where this hack is not necessary, we unnecessarily refetch
        a link
      - the platform cache first removes the link, adds it again and removes
        it. This is ugly, but should have no real consequences because all
        listeners to the platform signals delay processing the signals to an
        idle handler.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1285719
      
      This reverts commit f4f4e1cf.
      83240f24
    • Thomas Haller's avatar
      platform/tests: add test for missing netlink notification for IFA_LINK_NETNSID · 29c29372
      Thomas Haller authored
      The related bug rh#1262908 in kernel causes missing netlink notifications
      when moving a IFA_LINK interface to another netns.
      
      Add a test for our workaround.
      
      Related: https://bugzilla.redhat.com/show_bug.cgi?id=1262908
      29c29372
    • Thomas Haller's avatar
      platform: workaround kernel bug about missing IFLA_LINK/parent when creating veth · 5650c82a
      Thomas Haller authored
      The related bug rh#1285827 in kernel causes a missing IFLA_LINK/parent
      attribute when creating a veth pair:
      
          # ip monitor link &
          [1] 6745
      
          # ip link add dev vm1 type veth peer name vm2
          30: vm2@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
              link/ether be:e3:b7:0e:14:52 brd ff:ff:ff:ff:ff:ff
          31: vm1@vm2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
              link/ether da:e6:a6:c5:42:54 brd ff:ff:ff:ff:ff:ff
      
      Add a workaround and test.
      
      Related: https://bugzilla.redhat.com/show_bug.cgi?id=1285827
      5650c82a
    • Thomas Haller's avatar
      platform: add workaround for incomplete netlink link messages · 4488cf69
      Thomas Haller authored
      Due to kernel bugs [1], the first netlink event about a new link
      sometimes lacks the IFLA_LINKINFO with the link-type lnk data.
      
      In the case the data is missing, schedule a re-fetch the link
      hoping that it gets send.
      
      [1] https://bugzilla.redhat.com/show_bug.cgi?id=1284001
      4488cf69