1. 16 Oct, 2019 25 commits
  2. 15 Oct, 2019 7 commits
  3. 14 Oct, 2019 3 commits
    • Thomas Haller's avatar
      core: don't use pointer value for pending action string in active-connection · 10c63f16
      Thomas Haller authored
      The pending action gets logged. We should not log plain pointer
      values because they may be used to defeat ASLR.
      
      Instead, construct the pending action using the "version_id". This
      number is also unique, and suits sufficiently well. With debug logging
      you can still grep the log for the corresponding active-connection (and
      anyway it's obvious from the context).
      10c63f16
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      device: don't delay startup complete for pending-actions "autoconf", "dhcp4" and "dhcp6" · 1e520641
      Thomas Haller authored
      These "pending-actions" only have one purpose: to mark the device
      as busy and thereby delay "startup complete" to be reached. That
      in turn delays "NetworkManager-wait-online" service.
      
      Of course, "NetworkManager-wait-online" waits for some form of readiness
      and is not extensively configurable (e.g. you cannot exclude devices from
      being waited). However, the intent is to wait that all devices are "settled".
      That means among others, that the timeouts waiting for carrier and Wi-Fi scan
      results passed, and devices either don't have a connection profile to autoactivate,
      or they autoactivated profiles and are in state "connected".
      
      A major point here is that the device is considered ready, once it
      reaches the state "connected". Note that if you configure both IPv4 and
      IPv6 addressing modes, than "ipv4.may-fail=yes" and "ipv6.may-fail=yes"
      means, that the device is considered fully activated once one address
      family completes. Again, this is not very configurable, but by setting
      "ipv6.may-fail=no", you can require that the device has indeed IPv6
      addressing completed.
      
      Now, the determining factor for declaring "startup complete" is whether the
      device is in state "connected". That may or may not mean that DHCPv4,
      autoconf or DHCPv6 completed, as it depends on a overall state of the
      device. So, it is wrong to have distinct pending actions for these operations.
      
      Remove them.
      
      This fixes that we wrongly would wait too long before declaring startup
      complete. But it is also a change in behavior.
      1e520641
  4. 13 Oct, 2019 2 commits
  5. 12 Oct, 2019 2 commits
    • Thomas Haller's avatar
      clients/tests: fix handling timeout for asynchronous jobs · b6725a59
      Thomas Haller authored
      Fixes: bb4b7495 ('clients/tests: don't wait for first job before scheduling parallel jobs')
      b6725a59
    • Thomas Haller's avatar
      clients/tests: don't wait for first job before scheduling parallel jobs · bb4b7495
      Thomas Haller authored
      Previously, the test would kick off 15 processes in parallel, but
      the first job in the queue would block more processes from being
      started.
      
      That is, async_start() would only start 15 processes, but since none of
      them were reaped before async_wait() was called, no more than 15 jobs
      were running during the start phase. That is not a real issue, because
      the start phase is non-blocking and queues all the jobs quickly. It's
      not really expected that during that time many processes already completed.
      Anyway, this was a bit ugly.
      
      The bigger problem is that async_wait() would always block for the
      first job to complete, before starting more processes. That means,
      if the first job in the queue takes unusually long, then this blocks
      other processes from getting reaped and new processes from being
      started.
      
      Instead, don't block only one one jobs, but poll them in turn for a
      short amount of time. Whichever process exits first will be completed
      and more jobs will be started.
      
      In fact, in the current setup it's hard to notice any difference,
      because all nmcli invocations take about the same time and are
      relatively fast. That this approach parallelizes better can be seen
      when the runtime of jobs varies stronger (and some invocations take
      a notably longer time). As we later want to run nmcli under valgrind,
      this probably will make a difference.
      
      An alternative would be not to poll()/wait() for child processes,
      but somehow get notified. For example, we could use a GMainContext
      and watch child processes. But that's probably more complicated
      to do, so let's keep the naive approach with polling.
      bb4b7495
  6. 10 Oct, 2019 1 commit