1. 16 6月, 2017 8 次提交
  2. 25 5月, 2017 1 次提交
  3. 12 5月, 2017 1 次提交
  4. 27 4月, 2017 3 次提交
  5. 18 4月, 2017 1 次提交
    • F
      block: Walk bs->children carefully in bdrv_drain_recurse · 178bd438
      Fam Zheng 提交于
      The recursive bdrv_drain_recurse may run a block job completion BH that
      drops nodes. The coming changes will make that more likely and use-after-free
      would happen without this patch
      
      Stash the bs pointer and use bdrv_ref/bdrv_unref in addition to
      QLIST_FOREACH_SAFE to prevent such a case from happening.
      
      Since bdrv_unref accesses global state that is not protected by the AioContext
      lock, we cannot use bdrv_ref/bdrv_unref unconditionally.  Fortunately the
      protection is not needed in IOThread because only main loop can modify a graph
      with the AioContext lock held.
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Message-Id: <20170418143044.12187-2-famz@redhat.com>
      Reviewed-by: NJeff Cody <jcody@redhat.com>
      Tested-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NFam Zheng <famz@redhat.com>
      178bd438
  6. 11 4月, 2017 4 次提交
  7. 07 4月, 2017 1 次提交
  8. 13 3月, 2017 1 次提交
  9. 01 3月, 2017 3 次提交
  10. 21 2月, 2017 5 次提交
  11. 16 1月, 2017 1 次提交
    • P
      block: get rid of bdrv_io_unplugged_begin/end · 8f90b5e9
      Paolo Bonzini 提交于
      bdrv_io_plug and bdrv_io_unplug are only called (via their
      BlockBackend equivalents) after starting asynchronous I/O.
      bdrv_drain is not going to be called while they are running,
      because---even if a coroutine runs for some reason---it will
      only drain in the next iteration of the event loop through
      bdrv_co_yield_to_drain.
      
      So this mechanism is unnecessary, get rid of it.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 20161129113334.605-1-pbonzini@redhat.com
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      8f90b5e9
  12. 22 11月, 2016 2 次提交
    • E
      block: Pass unaligned discard requests to drivers · 3482b9bc
      Eric Blake 提交于
      Discard is advisory, so rounding the requests to alignment
      boundaries is never semantically wrong from the data that
      the guest sees.  But at least the Dell Equallogic iSCSI SANs
      has an interesting property that its advertised discard
      alignment is 15M, yet documents that discarding a sequence
      of 1M slices will eventually result in the 15M page being
      marked as discarded, and it is possible to observe which
      pages have been discarded.
      
      Between commits 9f1963b3 and b8d0a980, we converted the block
      layer to a byte-based interface that ultimately ignores any
      unaligned head or tail based on the driver's advertised
      discard granularity, which means that qemu 2.7 refuses to
      pass any discard request smaller than 15M down to the Dell
      Equallogic hardware.  This is a slight regression in behavior
      compared to earlier qemu, where a guest executing discards
      in power-of-2 chunks used to be able to get every page
      discarded, but is now left with various pages still allocated
      because the guest requests did not align with the hardware's
      15M pages.
      
      Since the SCSI specification says nothing about a minimum
      discard granularity, and only documents the preferred
      alignment, it is best if the block layer gives the driver
      every bit of information about discard requests, rather than
      rounding it to alignment boundaries early.
      
      Rework the block layer discard algorithm to mirror the write
      zero algorithm: always peel off any unaligned head or tail
      and manage that in isolation, then do the bulk of the request
      on an aligned boundary.  The fallback when the driver returns
      -ENOTSUP for an unaligned request is to silently ignore that
      portion of the discard request; but for devices that can pass
      the partial request all the way down to hardware, this can
      result in the hardware coalescing requests and discarding
      aligned pages after all.
      
      Reported by: Peter Lieven <pl@kamp.de>
      CC: qemu-stable@nongnu.org
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      3482b9bc
    • E
      block: Let write zeroes fallback work even with small max_transfer · b2f95fee
      Eric Blake 提交于
      Commit 443668ca rewrote the write_zeroes logic to guarantee that
      an unaligned request never crosses a cluster boundary.  But
      in the rewrite, the new code assumed that at most one iteration
      would be needed to get to an alignment boundary.
      
      However, it is easy to trigger an assertion failure: the Linux
      kernel limits loopback devices to advertise a max_transfer of
      only 64k.  Any operation that requires falling back to writes
      rather than more efficient zeroing must obey max_transfer during
      that fallback, which means an unaligned head may require multiple
      iterations of the write fallbacks before reaching the aligned
      boundaries, when layering a format with clusters larger than 64k
      atop the protocol of file access to a loopback device.
      
      Test case:
      
      $ qemu-img create -f qcow2 -o cluster_size=1M file 10M
      $ losetup /dev/loop2 /path/to/file
      $ qemu-io -f qcow2 /dev/loop2
      qemu-io> w 7m 1k
      qemu-io> w -z 8003584 2093056
      
      In fairness to Denis (as the original listed author of the culprit
      commit), the faulty logic for at most one iteration is probably all
      my fault in reworking his idea.  But the solution is to restore what
      was in place prior to that commit: when dealing with an unaligned
      head or tail, iterate as many times as necessary while fragmenting
      the operation at max_transfer boundaries.
      Reported-by: NEd Swierk <eswierk@skyportsystems.com>
      CC: qemu-stable@nongnu.org
      CC: Denis V. Lunev <den@openvz.org>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      b2f95fee
  13. 09 11月, 2016 1 次提交
  14. 31 10月, 2016 1 次提交
    • A
      block: Add bdrv_drain_all_{begin,end}() · c0778f66
      Alberto Garcia 提交于
      bdrv_drain_all() doesn't allow the caller to do anything after all
      pending requests have been completed but before block jobs are
      resumed.
      
      This patch splits bdrv_drain_all() into _begin() and _end() for that
      purpose. It also adds aio_{disable,enable}_external() calls to disable
      external clients in the meantime.
      
      An important restriction of this split is that no new block jobs or
      BlockDriverStates can be created between the bdrv_drain_all_begin()
      and bdrv_drain_all_end() calls. This is not a concern now because
      we'll only be using this in bdrv_reopen_multiple(), but it must be
      dealt with if we ever have other uses cases in the future.
      Signed-off-by: NAlberto Garcia <berto@igalia.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      c0778f66
  15. 28 10月, 2016 7 次提交