1. 01 10月, 2018 13 次提交
  2. 29 9月, 2018 1 次提交
  3. 27 9月, 2018 6 次提交
  4. 26 9月, 2018 15 次提交
  5. 25 9月, 2018 5 次提交
    • M
      lxc_monitor: Avoid AB / BA lock race · 7882c6ec
      Mark Asselstine 提交于
      A deadlock situation can occur when autostarting a LXC domain 'guest'
      due to two threads attempting to take opposing locks while holding
      opposing locks (AB BA problem). Thread A takes and holds the 'vm' lock
      while attempting to take the 'client' lock, meanwhile, thread B takes
      and holds the 'client' lock while attempting to take the 'vm' lock.
      
      The potential for this can be seen as follows:
      
      Thread A:
      virLXCProcessAutostartDomain (takes vm lock)
       --> virLXCProcessStart
        --> virLXCProcessConnectMonitor
         --> virLXCMonitorNew
          --> virNetClientSetCloseCallback (wants client lock)
      
      Thread B:
      virNetClientIncomingEvent (takes client lock)
       --> virNetClientIOHandleInput
        --> virNetClientCallDispatch
         --> virNetClientCallDispatchMessage
          --> virNetClientProgramDispatch
           --> virLXCMonitorHandleEventInit
            --> virLXCProcessMonitorInitNotify (wants vm lock)
      
      Since these threads are scheduled independently and are preemptible it
      is possible for the deadlock scenario to occur where each thread locks
      their first lock but both will fail to get their second lock and just
      spin forever. You get something like:
      
      virLXCProcessAutostartDomain (takes vm lock)
       --> virLXCProcessStart
        --> virLXCProcessConnectMonitor
         --> virLXCMonitorNew
      <...>
      virNetClientIncomingEvent (takes client lock)
       --> virNetClientIOHandleInput
        --> virNetClientCallDispatch
         --> virNetClientCallDispatchMessage
          --> virNetClientProgramDispatch
           --> virLXCMonitorHandleEventInit
            --> virLXCProcessMonitorInitNotify (wants vm lock but spins)
      <...>
          --> virNetClientSetCloseCallback (wants client lock but spins)
      
      Neither thread ever gets the lock it needs to be able to continue
      while holding the lock that the other thread needs.
      
      The actual window for preemption which can cause this deadlock is
      rather small, between the calls to virNetClientProgramNew() and
      execution of virNetClientSetCloseCallback(), both in
      virLXCMonitorNew(). But it can be seen in real world use that this
      small window is enough.
      
      By moving the call to virNetClientSetCloseCallback() ahead of
      virNetClientProgramNew() we can close any possible chance of the
      deadlock taking place. There should be no other implications to the
      move since the close callback (in the unlikely event was called) will
      spin on the vm lock. The remaining work that takes place between the
      old call location of virNetClientSetCloseCallback() and the new
      location is unaffected by the move.
      Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      7882c6ec
    • P
      vircgroup: rename controllers to legacy · 65ba48d2
      Pavel Hrdina 提交于
      With the introduction of cgroup v2 there are new names used with
      cgroups based on which version is used:
      
          - legacy: cgroup v1
          - unified: cgroup v2
          - hybrid: cgroup v1 and cgroup v2
      
      Let's use 'legacy' instead of 'cgroupv1' or 'controllers' in our code.
      Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      65ba48d2
    • P
    • P
      2b09065e
    • P