1. 22 Sep, 2014 2 commits
  2. 10 Sep, 2014 1 commit
  3. 15 Aug, 2014 2 commits
  4. 28 May, 2014 1 commit
    • Fam Zheng's avatar
      aio: Fix use-after-free in cancellation path · 271c0f68
      Fam Zheng authored
      The current flow of canceling a thread from THREAD_ACTIVE state is:
      
        1) Caller wants to cancel a request, so it calls thread_pool_cancel.
      
        2) thread_pool_cancel waits on the conditional variable
           elem->check_cancel.
      
        3) The worker thread changes state to THREAD_DONE once the task is
           done, and notifies elem->check_cancel to allow thread_pool_cancel
           to continue execution, and signals the notifier (pool->notifier) to
           allow callback function to be called later. But because of the
           global mutex, the notifier won't get processed until step 4) and 5)
           are done.
      
        4) thread_pool_cancel continues, leaving the notifier signaled, it
           just returns to caller.
      
        5) Caller thinks the request is already canceled successfully, so it
           releases any related data, such as freeing elem->common.opaque.
      
        6) In the next main loop iteration, the notifier handler,
           event_notifier_ready, is called. It finds the canceled thread in
           THREAD_DONE state, so calls elem->common.cb, with an (likely)
           dangling opaque pointer. This is a use-after-free.
      
      Fix it by calling event_notifier_ready before leaving
      thread_pool_cancel.
      
      Test case update: This change will let cancel complete earlier than
      test-thread-pool.c expects, so update the code to check this case: if
      it's already done, done_cb sets .aiocb to NULL, skip calling
      bdrv_aio_cancel on them.
      Reported-by: default avatarUlrich Obergfell <uobergfe@redhat.com>
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarFam Zheng <famz@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      271c0f68
  5. 09 Mar, 2014 1 commit
  6. 22 Aug, 2013 1 commit
  7. 19 Aug, 2013 2 commits
  8. 15 Mar, 2013 3 commits
    • Stefan Hajnoczi's avatar
      threadpool: drop global thread pool · c4d9d196
      Stefan Hajnoczi authored
      Now that each AioContext has a ThreadPool and the main loop AioContext
      can be fetched with bdrv_get_aio_context(), we can eliminate the concept
      of a global thread pool from thread-pool.c.
      
      The submit functions must take a ThreadPool* argument.
      
      block/raw-posix.c and block/raw-win32.c use
      aio_get_thread_pool(bdrv_get_aio_context(bs)) to fetch the main loop's
      ThreadPool.
      
      tests/test-thread-pool.c must be updated to reflect the new
      thread_pool_submit() function prototypes.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      c4d9d196
    • Stefan Hajnoczi's avatar
      threadpool: add thread_pool_new() and thread_pool_free() · f7311ccc
      Stefan Hajnoczi authored
      ThreadPool is tied to an AioContext through its event notifier, which
      dictates in which AioContext the work item's callback function will be
      invoked.
      
      In order to support multiple AioContexts we need to support multiple
      ThreadPool instances.
      
      This patch adds the new/free functions.  The free function deserves
      special attention because it quiesces remaining worker threads.  This
      requires a new condition variable and a "stopping" flag to let workers
      know they should terminate once idle.
      
      We never needed to do this before since the global threadpool was not
      explicitly destroyed until process termination.
      
      Also stash the AioContext pointer in ThreadPool so that we can call
      aio_set_event_notifier() in thread_pool_free().  We didn't need to hold
      onto AioContext previously since there was no free function.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f7311ccc
    • Stefan Hajnoczi's avatar
      threadpool: move globals into struct ThreadPool · b811203c
      Stefan Hajnoczi authored
      Move global variables into a struct so multiple thread pools can be
      supported in the future.
      
      This patch does not change thread-pool.h interfaces.  There is still a
      global thread pool and it is not yet possible to create/destroy
      individual thread pools.  Moving the variables into a struct first makes
      later patches easier to review.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b811203c
  9. 19 Dec, 2012 2 commits
  10. 14 Nov, 2012 1 commit
  11. 31 Oct, 2012 2 commits
    • Paolo Bonzini's avatar
      threadpool: do not take lock in event_notifier_ready · 19d092cf
      Paolo Bonzini authored
      The ordering is:
      
          worker thread                         consumer thread
          -------------------------------------------------------------------
          write ret                             event_notifier_test_and_clear
          wmb()                                 read state
          write state                           rmb()
          event_notifier_set                    read ret
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      19d092cf
    • Paolo Bonzini's avatar
      aio: add generic thread-pool facility · d354c7ec
      Paolo Bonzini authored
      Add a generic thread-pool.  The code is roughly based on posix-aio-compat.c,
      with some changes, especially the following:
      
      - use QemuSemaphore instead of QemuCond;
      
      - separate the state of the thread from the return code of the worker
      function.  The return code is totally opaque for the thread pool;
      
      - do not busy wait when doing cancellation.
      
      A more generic threadpool (but still specific to I/O so that in the future
      it can use special scheduling classes or PI mutexes) can have many uses:
      it allows more flexibility in raw-posix.c and can more easily be extended
      to Win32, and it will also be used to do an msync of the persistent bitmap.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d354c7ec