1. 22 Feb, 2019 4 commits
  2. 21 Feb, 2019 2 commits
  3. 19 Feb, 2019 2 commits
  4. 18 Feb, 2019 2 commits
  5. 17 Feb, 2019 1 commit
  6. 13 Feb, 2019 3 commits
  7. 12 Feb, 2019 10 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      shared: use nm_strerror_native_r() in lower layers · d83d5f1d
      Thomas Haller authored
      Subsequent calls to nm_strerror_native() overwrite the previous
      buffer. That is potentially dangerious. At least functions in
      shared/nm-utils (which are lower-layer utilities) should not do
      that and instead use a stack-local buffer. That is because these
      functions should not make assumptions about the way they are called.
      On the other end, nmcli passing the return-value of nm_strerror_native()
      to g_print() is clearly OK because the higher layers are in control of
      when the call nm_strerror_native() -- by relying that lower layers don't
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      shared: add nm_strerror_native() to replace strerror() and g_strerror() · e1ca3bf7
      Thomas Haller authored
      We have various options for strerror(), with ups and downsides:
      - strerror()
          - returns pointer that is overwritten on next call. It's convenient
            to use, but dangerous.
          - not thread-safe.
          - not guaranteed to be UTF-8.
      - strerror_r()
          - takes input buffer and is less convenient to use. At least, we
            are in control of when the buffer gets overwritten.
          - there is a Posix/XSI and a glibc variant, making it sligthly
            inconvenient to used. This could be solved by a wrapper we implement.
          - thread-safe.
          - not guaranteed to be UTF-8.
      - g_strerror()
          - convenient and safe to use. Also the buffer is never released for the
            remainder of the program.
          - passing untrusted error numbers to g_strerror() can result in a
            denial of service, as the internal buffer grows until out-of-memory.
          - thread-safe.
          - guaranteed to be UTF-8 (depending on locale).
      Add our own wrapper nm_strerror_native(). It is:
          - convenient to use (returning a buffer that does not require
          - slightly dangerous as the buffer gets overwritten on the next call
            (like strerror()).
          - thread-safe.
          - guaranteed to be UTF-8 (depending on locale).
          - doesn't keep an unlimited cache of strings, unlike g_strerror().
      You can't have it all. g_strerror() is leaking all generated error messages.
      I think that is unacceptable, because it would mean we need to
      keep track where our error numbers come from (and trust libraries we
      use to only set a restricted set of known error numbers).
    • Thomas Haller's avatar
      all: assert that native errno numbers are positive · 4d9918aa
      Thomas Haller authored
      Use the NM_ERRNO_NATIVE() macro that asserts that these errno numbers are
      indeed positive. Using the macro also serves as a documentation of what
      the meaning of these numbers is.
      That is often not obvious, whether we have an nm_errno(), an nm_errno_native()
      (from <errno.h>), or another error number (e.g. WaitForNlResponseResult). This
      situation already improved by merging netlink error codes (nle),
      NMPlatformError enum and <errno.h> as nm_errno(). But we still must
      always be careful about not to mix error codes from different
      domains or transform them appropriately (like nm_errno_from_native()).
    • Thomas Haller's avatar
      shared: cleanup separation and transition between errno and nmerr numbers · 67130e67
      Thomas Haller authored
      The native error numbers (from <errno.h>) and our nmerr extention on top
      of them are almost the same. But there are peculiarities.
      Both errno and nmerr must be positive values. That is because some API
      (systemd) like to return negative error codes. So, a positive errno and
      its negative counter part indicate the same error. We need normalization
      functions that make an error number positive (these are nm_errno() and
      This means, G_MININT needs special treatment, because it cannot be
      represented as a positive integer. Also, zero needs special
      treatment, because we want to encode an error, and zero already encodes
      no-error. Take care of these special cases.
      On top of that, nmerr reserves a range within native error numbers for
      NetworkManager specific failure codes. So we need to transition from native
      numbers to nmerr numbers via nm_errno_from_native().
      Take better care of some special cases and clean them up.
      Also add NM_ERRNO_NATIVE() macro. While nm_errno_native() coerces a
      value in the suitable range, NM_ERRNO_NATIVE() asserts that the number
      is already positive (and returns it as-is). It's use is only for
      asserting and implicitly documenting the requirements we have on the
      number passed to it.
    • Thomas Haller's avatar
      shared: fix nm_errno_from_native() for negative values · 89d3c524
      Thomas Haller authored
      We first need to map negative values to their positive form,
      and then do the check for the reserved range.
      Fixes: 18732c34
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      all: drop unnecessary includes of <errno.h> and <string.h> · a3370af3
      Thomas Haller authored
      "nm-macros-interal.h" already includes <errno.h> and <string.h>.
      No need to include it everywhere else too.
  8. 11 Feb, 2019 1 commit
  9. 08 Feb, 2019 1 commit
    • Thomas Haller's avatar
      shared: avoid "-Wmissing-braces" warning initalizing NMIPAddr · 395174f6
      Thomas Haller authored
      NMIPAddr contains an unnamed union. We have to either explicitly
      initialize one field, or omit it.
          ../shared/nm-utils/nm-shared-utils.c:38:36: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
          const NMIPAddr nm_ip_addr_zero = { 0 };
  10. 07 Feb, 2019 1 commit
    • Thomas Haller's avatar
      macros: don't use __externally_visible__ attribute for clang · 06701e95
      Thomas Haller authored
      clang does not support externally_visible:
          ../libnm/nm-access-point.c:243:1: error: unknown attribute externally_visible ignored [-Werror,-Wunknown-attributes]
          NM_BACKPORT_SYMBOL (libnm_1_0_6, int, nm_access_point_get_last_seen, (NMAccessPoint *ap), (ap));
          ../shared/nm-utils/nm-macros-internal.h:1299:74: note: expanded from macro NM_BACKPORT_SYMBOL
          #define NM_BACKPORT_SYMBOL(version, return_type, func, args_typed, args) \
          ../shared/nm-utils/nm-macros-internal.h:1292:17: note: expanded from macro _NM_BACKPORT_SYMBOL_IMPL
          __attribute__ ((externally_visible)) return_type versioned_func args_typed \
  11. 05 Feb, 2019 4 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      logging: make nm-logging thread-safe · fcfd4f4f
      Thomas Haller authored
      NetworkManager is single-threaded and uses a mainloop.
      However, sometimes we may need multiple threads. For example, we will
      need to write sysctl values asynchronously, using the glib thread-pool.
      For that to work, we also need to switch the network-namespace of the
      thread-pool thread. We want to use NMPNetns for that. Hence it's better
      to have NMPNetns thread-safe, instead of coming up with a duplicate
      implementation. But NMPNetns may want to log, so we also need nm-logging
      In general, code under "shared/nm-utils" and nm-logging should be usable
      from multiple threads. It's simpler to make this code thread-safe than
      re-implementing it. Also, it's a bad limitation to be unable to log
      from other threads. If there is an error, the best we can often do is to
      log about it.
      Make nm-logging thread-safe. Actually, we only need to be able to log
      from multiple threads. We don't need to setup or configure logging from
      multiple threads. This restriction allows us to access logging from the
      main-thread without any thread-synchronization (because all changes in
      the logging setup are also done from the main-thread).
      So, while logging from other threads requires a mutex, logging from the
      main-thread is lock-free.
    • Thomas Haller's avatar
      shared: define NM_THREAD_SAFE_ON_MAIN_THREAD · 40b0d7ce
      Thomas Haller authored
      This will be used by nm-logging to opportunistically avoid locking.
    • Thomas Haller's avatar
  12. 04 Feb, 2019 4 commits
  13. 24 Jan, 2019 1 commit
  14. 22 Jan, 2019 2 commits
    • Thomas Haller's avatar
      shared: add "struct in_addr" union member to NMIPAddr struct · 744e11dc
      Thomas Haller authored
      NMIPAddr is a union of IPv4 and IPv6 addresses.
      A lot of our internal API handles IPv4 as in_addr_t / guint32 / be32_t
      types, as such the union field "addr4" is just a plain number. Possibly
      the internal API should be all refactored to prefer "struct in_addr"
      instead, but that is yet to be done.
      Anyway, at a few places we will need also access to the IPv4 address in form of
      a `struct in_addr`. Add an alias for that.
      I am not too happy about the resulting naming. It would be nicer to have
          struct in_addr  addr4;
          struct in6_addr addr6;
          in_addr_t       s_addr4;
      but for now, don't do such renaming.
    • Thomas Haller's avatar
      shared: suppress -Wstringop-truncation warning in nm_strndup_a() · 035c4ad4
      Thomas Haller authored
      The compiler is too smart for nm_strndup_a(). The code is correct,
      suppress "-Wstringop-truncation" warning.
  15. 16 Jan, 2019 1 commit
  16. 15 Jan, 2019 1 commit