[Qemu-commits] [qemu/qemu] dacaa1: block: Don't use BLK_PERM_CONSISTENT_READ for form...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: dacaa16238cc5915a609ddaab4b7f81c4bceb9ae
      
https://github.com/qemu/qemu/commit/dacaa16238cc5915a609ddaab4b7f81c4bceb9ae
  Author: Kevin Wolf <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block.c

  Log Message:
  -----------
  block: Don't use BLK_PERM_CONSISTENT_READ for format probing

For format probing, we don't really care whether all of the image
content is consistent. The only thing we're looking at is the image
header, and specifically the magic numbers that are expected to never
change, no matter how inconsistent the guest visible disk content is.

Therefore, don't request BLK_PERM_CONSISTENT_READ. This allows to use
format probing, e.g. in the context of 'qemu-img info', even while the
guest visible data in the image is inconsistent during a running block
job.

Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>


  Commit: 1f4ad7d3b8f7162ec0471506d86f57a5d77b8f76
      
https://github.com/qemu/qemu/commit/1f4ad7d3b8f7162ec0471506d86f57a5d77b8f76
  Author: Kevin Wolf <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block/block-backend.c

  Log Message:
  -----------
  block: Don't request I/O permission with BDRV_O_NO_IO

'qemu-img info' makes sense even when BLK_PERM_CONSISTENT_READ cannot be
granted because of a block job in a running qemu process. It already
sets BDRV_O_NO_IO to indicate that it doesn't access the guest visible
data at all.

Check the BDRV_O_NO_IO flags in blk_new_open(), so that I/O related
permissions are not unnecessarily requested and 'qemu-img info' can work
even if BLK_PERM_CONSISTENT_READ cannot be granted.

Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Reviewed-by: Alberto Garcia <address@hidden>


  Commit: 0b62bcbc61c0cd4c9e7fb3863cf5dc8016b0b4ed
      
https://github.com/qemu/qemu/commit/0b62bcbc61c0cd4c9e7fb3863cf5dc8016b0b4ed
  Author: Kevin Wolf <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block/snapshot.c
    M include/block/snapshot.h
    M qemu-img.c

  Log Message:
  -----------
  block: Add errp to bdrv_snapshot_goto()

Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: John Snow <address@hidden>


  Commit: 2b624fe079ee7123797f6c685e714795665c0e01
      
https://github.com/qemu/qemu/commit/2b624fe079ee7123797f6c685e714795665c0e01
  Author: Kevin Wolf <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block/snapshot.c
    M include/block/snapshot.h
    M migration/savevm.c

  Log Message:
  -----------
  block: Add errp to bdrv_all_goto_snapshot()

Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Denis V. Lunev <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: John Snow <address@hidden>


  Commit: 70a5afedd64c3f0d3b5feae6b40b30f3e8d13e4b
      
https://github.com/qemu/qemu/commit/70a5afedd64c3f0d3b5feae6b40b30f3e8d13e4b
  Author: Kevin Wolf <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block/snapshot.c

  Log Message:
  -----------
  block: Error out on load_vm with active dirty bitmaps

Loading a snapshot invalidates the bitmap. Just marking all blocks dirty
is not a useful response in practice, instead the user needs to be aware
that we switch to a completely different state. If they are okay with
losing the dirty bitmap, they can just explicitly delete it.

This effectively reverts commit 04dec3c3ae5.

Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Denis V. Lunev <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: John Snow <address@hidden>


  Commit: 50a3efb0f05bcfbe04201d4ebac0b96551a1b551
      
https://github.com/qemu/qemu/commit/50a3efb0f05bcfbe04201d4ebac0b96551a1b551
  Author: Alberto Garcia <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block.c
    M tests/qemu-iotests/060
    M tests/qemu-iotests/060.out

  Log Message:
  -----------
  block: Close a BlockDriverState completely even when bs->drv is NULL

bdrv_close() skips much of its logic when bs->drv is NULL. This is
fine when we're closing a BlockDriverState that has just been created
(because e.g the initialization process failed), but it's not enough
in other cases.

For example, when a valid qcow2 image is found to be corrupted then
QEMU marks it as such in the file header and then sets bs->drv to
NULL in order to make the BlockDriverState unusable. When that BDS is
later closed then many of its data structures are not freed (leaking
their memory) and none of its children are detached. This results in
bdrv_close_all() failing to close all BDSs and making this assertion
fail when QEMU is being shut down:

   bdrv_close_all: Assertion `QTAILQ_EMPTY(&all_bdrv_states)' failed.

This patch makes bdrv_close() do the full uninitialization process
in all cases. This fixes the problem with corrupted images and still
works fine with freshly created BDSs.

Signed-off-by: Alberto Garcia <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: 2807746ff178fe2e62638755693ece57aeeacc05
      
https://github.com/qemu/qemu/commit/2807746ff178fe2e62638755693ece57aeeacc05
  Author: Eric Blake <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M tests/qemu-iotests/176
    M tests/qemu-iotests/176.out

  Log Message:
  -----------
  iotests: Fix 176 on 32-bit host

The contents of a qcow2 bitmap are rounded up to a size that
matches the number of bits available for the granularity, but
that granularity differs for 32-bit hosts (our default 64k
cluster allows for 2M bitmap coverage per 'long') and 64-bit
hosts (4M bitmap per 'long').  If the image is a multiple of
2M but not 4M, then the number of bytes occupied by the array
of longs in memory differs between architecture, thus
resulting in different SHA256 hashes.

Furthermore (but untested by me), if our computation of the
SHA256 hash is at all endian-dependent because of how we store
data in memory, that's another variable we'd have to account
for (ideally, we specified the bitmap stored in qcow2 as
fixed-endian on disk, because the same qcow2 file must be
usable across any architecture; but that says nothing about
how we represent things in memory).  But we already have test
165 to validate that bitmaps are stored correctly on disk,
while this test is merely testing that the bitmap exists.

So for this test, the easiest solution is to filter out the
actual hash value.  Broken in commit 4096974e.

Reported-by: Max Reitz <address@hidden>
Signed-off-by: Eric Blake <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: 4fd0295c151e596944be2f8062c4563cdf9106a0
      
https://github.com/qemu/qemu/commit/4fd0295c151e596944be2f8062c4563cdf9106a0
  Author: Kevin Wolf <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block.c
    M tests/qemu-iotests/060
    M tests/qemu-iotests/060.out
    M tests/qemu-iotests/176
    M tests/qemu-iotests/176.out

  Log Message:
  -----------
  Merge remote-tracking branch 'mreitz/tags/pull-block-2017-11-21' into 
queue-block

Block patches for 2.11.0-rc2

# gpg: Signature made Tue Nov 21 14:54:28 2017 CET
# gpg:                using RSA key F407DB0061D5CF40
# gpg: Good signature from "Max Reitz <address@hidden>"
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1  1829 F407 DB00 61D5 CF40

* mreitz/tags/pull-block-2017-11-21:
  iotests: Fix 176 on 32-bit host
  block: Close a BlockDriverState completely even when bs->drv is NULL

Signed-off-by: Kevin Wolf <address@hidden>


  Commit: fc7dbc119e0852a70dc9fa68bb41a318e49e4cd6
      
https://github.com/qemu/qemu/commit/fc7dbc119e0852a70dc9fa68bb41a318e49e4cd6
  Author: Peter Maydell <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M block.c
    M block/block-backend.c
    M block/snapshot.c
    M include/block/snapshot.h
    M migration/savevm.c
    M qemu-img.c
    M tests/qemu-iotests/060
    M tests/qemu-iotests/060.out
    M tests/qemu-iotests/176
    M tests/qemu-iotests/176.out

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging

Block layer patches for 2.11.0-rc2

# gpg: Signature made Tue 21 Nov 2017 15:09:12 GMT
# gpg:                using RSA key 0x7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <address@hidden>"
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74  56FE 7F09 B272 C88F 2FD6

* remotes/kevin/tags/for-upstream:
  iotests: Fix 176 on 32-bit host
  block: Close a BlockDriverState completely even when bs->drv is NULL
  block: Error out on load_vm with active dirty bitmaps
  block: Add errp to bdrv_all_goto_snapshot()
  block: Add errp to bdrv_snapshot_goto()
  block: Don't request I/O permission with BDRV_O_NO_IO
  block: Don't use BLK_PERM_CONSISTENT_READ for format probing

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/7c3d1917fd7a...fc7dbc119e08