Skip to content
Snippets Groups Projects
  1. Mar 06, 2018
  2. Feb 09, 2018
  3. Feb 08, 2018
    • Paolo Bonzini's avatar
      coroutine-lock: make qemu_co_enter_next thread-safe · 5261dd7b
      Paolo Bonzini authored
      
      qemu_co_queue_next does not need to release and re-acquire the mutex,
      because the queued coroutine does not run immediately.  However, this
      does not hold for qemu_co_enter_next.  Now that qemu_co_queue_wait
      can synchronize (via QemuLockable) with code that is not running in
      coroutine context, it's important that code using qemu_co_enter_next
      can easily use a standardized locking idiom.
      
      First of all, qemu_co_enter_next must use aio_co_wake to restart the
      coroutine.  Second, the function gains a second argument, a QemuLockable*,
      and the comments of qemu_co_queue_next and qemu_co_queue_restart_all
      are adjusted to clarify the difference.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Message-Id: <20180203153935.8056-5-pbonzini@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarFam Zheng <famz@redhat.com>
      Signed-off-by: default avatarFam Zheng <famz@redhat.com>
      5261dd7b
  4. Jan 08, 2018
  5. Sep 05, 2017
  6. Aug 30, 2017
  7. Jul 18, 2017
  8. Jun 29, 2017
    • Tobias Schramm's avatar
      9pfs: local: Add support for custom fmode/dmode in 9ps mapped security modes · b96feb2c
      Tobias Schramm authored
      
      In mapped security modes, files are created with very restrictive
      permissions (600 for files and 700 for directories). This makes
      file sharing between virtual machines and users on the host rather
      complicated. Imagine eg. a group of users that need to access data
      produced by processes on a virtual machine. Giving those users access
      to the data will be difficult since the group access mode is always 0.
      
      This patch makes the default mode for both files and directories
      configurable. Existing setups that don't know about the new parameters
      keep using the current secure behavior.
      
      Signed-off-by: default avatarTobias Schramm <tobleminer@gmail.com>
      Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
      b96feb2c
  9. May 25, 2017
  10. Feb 28, 2017
  11. Nov 23, 2016
  12. Oct 17, 2016
    • Greg Kurz's avatar
      bc70a592
    • Li Qiang's avatar
      9pfs: allocate space for guest originated empty strings · ba42ebb8
      Li Qiang authored
      
      If a guest sends an empty string paramater to any 9P operation, the current
      code unmarshals it into a V9fsString equal to { .size = 0, .data = NULL }.
      
      This is unfortunate because it can cause NULL pointer dereference to happen
      at various locations in the 9pfs code. And we don't want to check str->data
      everywhere we pass it to strcmp() or any other function which expects a
      dereferenceable pointer.
      
      This patch enforces the allocation of genuine C empty strings instead, so
      callers don't have to bother.
      
      Out of all v9fs_iov_vunmarshal() users, only v9fs_xattrwalk() checks if
      the returned string is empty. It now uses v9fs_string_size() since
      name.data cannot be NULL anymore.
      
      Signed-off-by: default avatarLi Qiang <liqiang6-s@360.cn>
      [groug, rewritten title and changelog,
       fix empty string check in v9fs_xattrwalk()]
      Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
      ba42ebb8
  13. Sep 16, 2016
  14. Jul 12, 2016
  15. Jul 01, 2016
  16. Jun 07, 2016
  17. Jun 06, 2016
  18. Mar 16, 2016
  19. Feb 23, 2016
  20. Feb 11, 2016
  21. Jan 29, 2016
  22. Jan 26, 2016
  23. Jan 22, 2016
  24. Jan 08, 2016
Loading