[Qemu-commits] [qemu/qemu] d38d6d: util/ioc.c: try to reassure Coverity about qemu_io...

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: d38d6de2a1fe209c849e8392f99e214d0a2db319
      
https://github.com/qemu/qemu/commit/d38d6de2a1fe209c849e8392f99e214d0a2db319
  Author: Vladimir Sementsov-Ogievskiy <address@hidden>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M util/iov.c

  Log Message:
  -----------
  util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended

Make it more obvious, that filling qiov corresponds to qiov allocation,
which in turn corresponds to total_niov calculation, based on mid_niov
(not mid_len). Still add an assertion to show that there should be no
difference.

[Added mingw "error: 'mid_iov' may be used uninitialized in this
function" compiler error fix suggested by Vladimir.
--Stefan]

Reported-by: Coverity (CID 1405302)
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Suggested-by: Peter Maydell <address@hidden>
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>

fixup! util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended


  Commit: 9b92fbcf45ed6ed1daceba8480b0d9e8a327b5ce
      
https://github.com/qemu/qemu/commit/9b92fbcf45ed6ed1daceba8480b0d9e8a327b5ce
  Author: Sergio Lopez <address@hidden>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M hw/block/virtio-blk.c

  Log Message:
  -----------
  virtio-blk: schedule virtio_notify_config to run on main context

virtio_notify_config() needs to acquire the global mutex, which isn't
allowed from an iothread, and may lead to a deadlock like this:

 - main thead
  * Has acquired: qemu_global_mutex.
  * Is trying the acquire: iothread AioContext lock via
    AIO_WAIT_WHILE (after aio_poll).

 - iothread
  * Has acquired: AioContext lock.
  * Is trying to acquire: qemu_global_mutex (via
    virtio_notify_config->prepare_mmio_access).

If virtio_blk_resize() is called from an iothread, schedule
virtio_notify_config() to be run in the main context BH.

[Removed unnecessary newline as suggested by Kevin Wolf
<address@hidden>.
--Stefan]

Signed-off-by: Sergio Lopez <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Message-id: address@hidden
Message-Id: <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: 8644476e51fa33d7ab637b36b1306d0d4c66177c
      
https://github.com/qemu/qemu/commit/8644476e51fa33d7ab637b36b1306d0d4c66177c
  Author: Max Reitz <address@hidden>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M block/io.c

  Log Message:
  -----------
  block: Skip COR for inactive nodes

We must not write data to inactive nodes, and a COR is certainly
something we can simply not do without upsetting anyone.  So skip COR
operations on inactive nodes.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Message-Id: <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: 4d804b5305ffb4d5fa414c38d4f1bdfb987c8d0b
      
https://github.com/qemu/qemu/commit/4d804b5305ffb4d5fa414c38d4f1bdfb987c8d0b
  Author: Max Reitz <address@hidden>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

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

  Log Message:
  -----------
  iotests/262: Switch source/dest VM launch order

Launching the destination VM before the source VM gives us a regression
test for HEAD^:

The guest device causes a read from the disk image through
guess_disk_lchs().  This will not work if the first sector (containing
the partition table) is yet unallocated, we use COR, and the node is
inactive.

By launching the source VM before the destination, however, the COR
filter on the source will allocate that area in the image shared between
both VMs, thus the problem will not become apparent.

Switching the launch order causes the sector to still be unallocated
when guess_disk_lchs() runs on the inactive node in the destination VM,
and thus we get our test case.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Message-Id: <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d
      
https://github.com/qemu/qemu/commit/98b2e3c9ab3abfe476a2b02f8f51813edb90e72d
  Author: Peter Maydell <address@hidden>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M block/io.c
    M hw/block/virtio-blk.c
    M tests/qemu-iotests/262
    M tests/qemu-iotests/262.out
    M util/iov.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging

Pull request

This pull request also contains the two commits from the previous pull request
that was dropped due to a mingw compilation error.  The compilation should now
be fixed.

# gpg: Signature made Tue 08 Oct 2019 15:54:26 BST
# gpg:                using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <address@hidden>" [full]
# gpg:                 aka "Stefan Hajnoczi <address@hidden>" [full]
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35  775A 9CA4 ABB3 81AB 73C8

* remotes/stefanha/tags/block-pull-request:
  iotests/262: Switch source/dest VM launch order
  block: Skip COR for inactive nodes
  virtio-blk: schedule virtio_notify_config to run on main context
  util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended

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


Compare: https://github.com/qemu/qemu/compare/14d40ab1d55e...98b2e3c9ab3a