1. 23 Aug, 2019 1 commit
  2. 12 Aug, 2019 1 commit
  3. 06 Aug, 2019 1 commit
  4. 05 Aug, 2019 1 commit
  5. 03 Aug, 2019 2 commits
  6. 01 Aug, 2019 6 commits
    • Thomas Haller's avatar
      core/lldp: minor cleanup in _lldp_attr_*() · 134ccb4a
      Thomas Haller authored
      - use nm_g_variant_unref_floating()
      
      - rename _lldp_attr_take_str_ptr() to _lldp_attr_set_str_take().
        The new name has the same "_lldp_attr_set_" prefix as other setters.
        Also, with the previous name it is unclear why it takes a "str-ptr".
      
      - setting the same attribute multiple times, ignores all but the first
        value. Avoid cloning the string in that case, and explicitly choose
        the set or take function.
      
      (cherry picked from commit 0fbb5483)
      (cherry picked from commit d84d1db3)
      134ccb4a
    • Thomas Haller's avatar
      core/lldp: fix memleak in _lldp_attr_take_str_ptr() · 5233a02e
      Thomas Haller authored
      Valgrind complains:
      
        ==26355== 32 bytes in 2 blocks are definitely lost in loss record 2,829 of 6,716
        ==26355==    at 0x4838748: malloc (vg_replace_malloc.c:308)
        ==26355==    by 0x483AD63: realloc (vg_replace_malloc.c:836)
        ==26355==    by 0x4F6AD4F: g_realloc (in /usr/lib64/libglib-2.0.so.0.6000.6)
        ==26355==    by 0x4F87B33: ??? (in /usr/lib64/libglib-2.0.so.0.6000.6)
        ==26355==    by 0x4F87B96: g_string_sized_new (in /usr/lib64/libglib-2.0.so.0.6000.6)
        ==26355==    by 0x2D66E1: nm_utils_buf_utf8safe_escape (nm-shared-utils.c:1911)
        ==26355==    by 0x4113B0: lldp_neighbor_new (nm-lldp-listener.c:676)
        ==26355==    by 0x412788: process_lldp_neighbor (nm-lldp-listener.c:882)
        ==26355==    by 0x4135CF: lldp_event_handler (nm-lldp-listener.c:931)
        ==26355==    by 0x422CDB: lldp_callback (sd-lldp.c:50)
        ==26355==    by 0x4235F9: lldp_add_neighbor (sd-lldp.c:166)
        ==26355==    by 0x423679: lldp_handle_datagram (sd-lldp.c:189)
        ==26355==    by 0x423C8B: lldp_receive_datagram (sd-lldp.c:235)
        ==26355==    by 0x2F887A: source_dispatch (sd-event.c:2832)
        ==26355==    by 0x2FAD43: sd_event_dispatch (sd-event.c:3245)
        ==26355==    by 0x2D9237: event_dispatch (nm-sd.c:51)
        ==26355==    by 0x4F64EDC: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6000.6)
        ==26355==    by 0x4F6526F: ??? (in /usr/lib64/libglib-2.0.so.0.6000.6)
        ==26355==    by 0x4F655A2: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.6000.6)
        ==26355==    by 0x140932: main (main.c:465)
        ==26355==
      
      (cherry picked from commit ece270ea)
      (cherry picked from commit 273f0b54)
      5233a02e
    • Beniamino Galvani's avatar
      ovs: don't release slaves on quit · a1f39b69
      Beniamino Galvani authored
      An OVS bridge and its slaves can continue to work even after NM has
      quit. Keep the interface enslaved when the @configure argument of
      device->release_slave() is FALSE, which happens on quit and in other
      circumstances when we don't really want to release the slave from its
      master.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1733709
      !215
      (cherry picked from commit ccd4be40)
      a1f39b69
    • Beniamino Galvani's avatar
      merge: branch 'bg/ovs-restart-part2-rh1733709' · e066ac55
      Beniamino Galvani authored
      !216
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1733709
      (cherry picked from commit 5f668b81)
      (cherry picked from commit 0581a53a)
      e066ac55
    • Beniamino Galvani's avatar
      device: fix releasing slaves · f6a90b89
      Beniamino Galvani authored
      Not all masters type have a platform link and so it's wrong to check
      for it to decide whether the slave should be really released. Move the
      check to master devices that need it (bond, bridge and team).
      
      OVS ports don't need the check because they don't call to platform to
      remove a slave.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1733709
      (cherry picked from commit 57e3734b)
      (cherry picked from commit ec1b5fb0)
      f6a90b89
    • Beniamino Galvani's avatar
      device: check platform link compatibility when setting nm-owned flag · 511ef27d
      Beniamino Galvani authored
      We set nm-owned to indicate whether a software device was created by
      NM or it was pre-existing. When checking the existence, we must verify
      also whether the link type is compatible with the device, otherwise it
      is possible to match unrelated interfaces. For example, when checking
      for the existence of an ovs-bridge (which is not compatible with any
      platform link) we could match a unrelated platform link with the same
      name.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1733709
      (cherry picked from commit 3cb4b362)
      (cherry picked from commit cb20d079)
      511ef27d
  7. 26 Jul, 2019 1 commit
  8. 25 Jul, 2019 3 commits
    • Thomas Haller's avatar
      policy-routing: take ownership of externally configured rules · a3e51a74
      Thomas Haller authored
      IP addresses, routes, TC and QDiscs are all tied to a certain interface.
      So when NetworkManager manages an interface, it can be confident that
      all related entires should be managed, deleted and modified by NetworkManager.
      
      Routing policy rules are global. For that we have NMPRulesManager which
      keeps track of whether NetworkManager owns a rule. This allows multiple
      connection profiles to specify the same rule, and NMPRulesManager can
      consolidate this information to know whether to add or remove the rule.
      
      NMPRulesManager would also support to explicitly block a rule by
      tracking it with negative priority. However that is still unused at
      the moment. All that devices do is to add rules (track with positive
      priority) and remove them (untrack) once the profile gets deactivated.
      
      As rules are not exclusively owned by NetworkManager, NetworkManager
      tries not to interfere with rules that it knows nothing about. That
      means in particular, when NetworkManager starts it will "weakly track"
      all rules that are present. "weakly track" is mostly interesting for two
      cases:
      
        - when NMPRulesManager had the same rule explicitly tracked (added) by a
          device, then deactivating the device will leave the rule in place.
      
        - when NMPRulesManager had the same rule explicitly blocked (tracked
          with negative priority), then it would restore the rule when that
          block gets removed (as said, currently nobody actually does this).
      
      Note that when restarting NetworkManager, then the device may stay and
      the rules kept. However after restart, NetworkManager no longer knows
      that it previously added this route, so it would weakly track it and
      never remove them again.
      
      That is a problem. Avoid that, by whenever explicitly tracking a rule we
      also make sure to no longer weakly track it. Most likely this rule was
      indeed previously managed by NetworkManager. If this was really a rule
      added by externally, then the user really should choose distinct
      rule priorities to avoid such conflicts altogether.
      
      (cherry picked from commit 15b13044)
      a3e51a74
    • Thomas Haller's avatar
      libnm: accept special table names for policy-routing · a55467a3
      Thomas Haller authored
      The tables "main", "local", and "default" have well known names.
      Accept them as aliases when parsing the string representation of
      the rule.
      
      Note that iproute2 also considers /etc/iproute2/rt_tables for table
      names. In particular, that allows a user to re-map the well-known names
      like "main" to a different table. We never honor that file, and "main"
      always means table 254.
      
      Note that this only affects how we parse the string representation for
      rules. As the representation is neither unique nor enforced to be normalized,
      being more graceful here is no problem.
      
      The point is of course that the user possibly has existing iproute2
      scripts that use such keyword. This makes it simpler to copy & paste
      the rule.
      
      (cherry picked from commit 70b23c79)
      a55467a3
    • Lubomir Rintel's avatar
      74702168
  9. 24 Jul, 2019 12 commits
  10. 23 Jul, 2019 1 commit
  11. 22 Jul, 2019 1 commit
  12. 18 Jul, 2019 2 commits
  13. 09 Jul, 2019 1 commit
  14. 04 Jul, 2019 1 commit
  15. 03 Jul, 2019 1 commit
  16. 27 Jun, 2019 1 commit
  17. 26 Jun, 2019 1 commit
  18. 20 Jun, 2019 3 commits