Re: [libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
On 7/18/19 6:20 AM, no-re...@patchew.org wrote: > PASS 17 test-bdrv-drain /bdrv-drain/graph-change/drain_all > = > ==10263==ERROR: AddressSanitizer: heap-use-after-free on address > 0x6122c1f0 at pc 0x555fd5bd7cb6 bp 0x7f3e853b8680 sp 0x7f3e853b8678 > WRITE of size 1 at 0x6122c1f0 thread T5 > ==10262==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > #0 0x555fd5bd7cb5 in aio_notify /tmp/qemu-test/src/util/async.c:351:9 > #1 0x555fd5bd98eb in qemu_bh_schedule > /tmp/qemu-test/src/util/async.c:167:9 > #2 0x555fd5bdcaf0 in aio_co_schedule /tmp/qemu-test/src/util/async.c:464:5 I'm fairly certain that this isn't related to this patch. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
Patchew URL: https://patchew.org/QEMU/20190717173937.18747-1-js...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===
PASS 32 test-opts-visitor /visitor/opts/range/beyond
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl
--test-name="test-coroutine"
==10068==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
==10068==WARNING: ASan is ignoring requested __asan_handle_no_return: stack
top: 0x7fff27ea5000; bottom 0x7f02672f8000; size: 0x00fcc0bad000 (1085565227008)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-coroutine /basic/no-dangling-access
---
PASS 1 fdc-test /x86_64/fdc/cmos
PASS 2 fdc-test /x86_64/fdc/no_media_on_start
PASS 3 fdc-test /x86_64/fdc/read_without_media
==10065==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
PASS 6 fdc-test /x86_64/fdc/relative_seek
---
PASS 11 test-aio /aio/event/wait
PASS 12 test-aio /aio/event/flush
PASS 13 test-aio /aio/event/wait/no-flush-cb
==10091==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 14 test-aio /aio/timer/schedule
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
PASS 28 test-aio /aio-gsource/timer/schedule
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-aio-multithread -m=quick -k --tap < /dev/null |
./scripts/tap-driver.pl --test-name="test-aio-multithread"
PASS 1 test-aio-multithread /aio/multi/lifecycle
==10097==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 2 test-aio-multithread /aio/multi/schedule
PASS 12 fdc-test /x86_64/fdc/read_no_dma_19
PASS 3 test-aio-multithread /aio/multi/mutex/contended
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img
tests/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl
--test-name="ide-test"
==10125==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 1 ide-test /x86_64/ide/identify
==10131==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
PASS 2 ide-test /x86_64/ide/flush
==10142==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
==10154==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl
--test-name="test-throttle"
PASS 1 test-throttle /throttle/leak_bucket
==10161==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 2 test-throttle /throttle/compute_wait
PASS 3 test-throttle /throttle/init
PASS 4 test-throttle /throttle/destroy
---
PASS 15 test-throttle /throttle/config/iops_size
PASS 4 ide-test /x86_64/ide/bmdma/trim
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-thread-pool -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl
--test-name="test-thread-pool"
==10169==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
==10166==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 1 test-thread-pool /thread-pool/submit
PASS 2 test-thread-pool /thread-pool/submit-aio
PASS 3 test-thread-pool /thread-pool/submit-co
PASS 4 test-thread-pool /thread-pool/submit-many
PASS 5 ide-test /x86_64/ide/bmdma/short_prdt
==10177==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 6 ide-test /x86_64/ide/bmdma/one_sector_short_prdt
==10183==WARNING: ASan doesn't fully support makecontext/swapcontext
Re: [libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
On 7/17/19 4:05 PM, Eric Blake wrote: > On 7/17/19 2:21 PM, John Snow wrote: >>> >>> Is this worth squeezing into 4.1, to start the deprecation clock one >>> cycle earlier (on the grounds that the missing information for anonymous >>> nodes is a bug)? Or am I pushing the boundaries too far, where keeping >>> this as 4.2 material remains the best course of action? >>> >> >> Appealing option. If you think the deprecation plan is actionable enough >> for libvirt, I'm in favor. > > I know my code for scraping query-block output during > virDomainCheckpointGetXMLDesc(,VIR_DOMAIN_CHECKPOINT_XML_SIZE) that > reports the size of the bitmap to the end user hasn't landed yet, and > that appears to be the only client in libvirt of this information at the > moment; but it's not a problem for me to check introspection for where > to find it (as libvirt already has a good framework for scraping > introspection for other reasons). > Ah, well... rc1 was yesterday already, so actually I think it's probably just really too late to do this. --js -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
On 7/17/19 2:21 PM, John Snow wrote: >> >> Is this worth squeezing into 4.1, to start the deprecation clock one >> cycle earlier (on the grounds that the missing information for anonymous >> nodes is a bug)? Or am I pushing the boundaries too far, where keeping >> this as 4.2 material remains the best course of action? >> > > Appealing option. If you think the deprecation plan is actionable enough > for libvirt, I'm in favor. I know my code for scraping query-block output during virDomainCheckpointGetXMLDesc(,VIR_DOMAIN_CHECKPOINT_XML_SIZE) that reports the size of the bitmap to the end user hasn't landed yet, and that appears to be the only client in libvirt of this information at the moment; but it's not a problem for me to check introspection for where to find it (as libvirt already has a good framework for scraping introspection for other reasons). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
On 7/17/19 3:13 PM, Eric Blake wrote: > On 7/17/19 12:39 PM, John Snow wrote: >> From: Vladimir Sementsov-Ogievskiy >> >> Let's add a possibility to query dirty-bitmaps not only on root nodes. >> It is useful when dealing both with snapshots and incremental backups. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy >> [Added deprecation information. --js] >> Signed-off-by: John Snow >> --- >> block/qapi.c | 5 + >> qapi/block-core.json | 6 +- >> qemu-deprecated.texi | 12 >> 3 files changed, 22 insertions(+), 1 deletion(-) > >> +++ b/qapi/block-core.json >> @@ -360,6 +360,9 @@ >> # @write_threshold: configured write threshold for the device. >> # 0 if disabled. (Since 2.3) >> # >> +# @dirty-bitmaps: dirty bitmaps information (only present if node >> +# has one or more dirty bitmaps) (Since 4.2) >> +# > > Naming-wise, everything else in this struct uses 'foo_bar' while your > addition uses 'foo-bar'. But at this point, I don't know if it's worth > uglifying this addition just to fit in. > >> # Since: 0.14.0 >> # >> ## >> @@ -378,7 +381,7 @@ >> '*bps_wr_max_length': 'int', '*iops_max_length': 'int', >> '*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int', >> '*iops_size': 'int', '*group': 'str', 'cache': >> 'BlockdevCacheInfo', >> -'write_threshold': 'int' } } >> +'write_threshold': 'int', '*dirty-bitmaps': ['BlockDirtyInfo'] >> } } >> >> ## >> # @BlockDeviceIoStatus: >> @@ -656,6 +659,7 @@ >> # >> # @dirty-bitmaps: dirty bitmaps information (only present if the >> # driver has one or more dirty bitmaps) (Since 2.0) >> +# Deprecated in 4.2; see BlockDirtyInfo instead. > > s/BlockDirtyInfo/BlockDeviceInfo/ > > With the spelling fix, > Sigh, oops. > Reviewed-by: Eric Blake > > Is this worth squeezing into 4.1, to start the deprecation clock one > cycle earlier (on the grounds that the missing information for anonymous > nodes is a bug)? Or am I pushing the boundaries too far, where keeping > this as 4.2 material remains the best course of action? > Appealing option. If you think the deprecation plan is actionable enough for libvirt, I'm in favor. --js -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
On 7/17/19 12:39 PM, John Snow wrote: > From: Vladimir Sementsov-Ogievskiy > > Let's add a possibility to query dirty-bitmaps not only on root nodes. > It is useful when dealing both with snapshots and incremental backups. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > [Added deprecation information. --js] > Signed-off-by: John Snow > --- > block/qapi.c | 5 + > qapi/block-core.json | 6 +- > qemu-deprecated.texi | 12 > 3 files changed, 22 insertions(+), 1 deletion(-) > +++ b/qapi/block-core.json > @@ -360,6 +360,9 @@ > # @write_threshold: configured write threshold for the device. > # 0 if disabled. (Since 2.3) > # > +# @dirty-bitmaps: dirty bitmaps information (only present if node > +# has one or more dirty bitmaps) (Since 4.2) > +# Naming-wise, everything else in this struct uses 'foo_bar' while your addition uses 'foo-bar'. But at this point, I don't know if it's worth uglifying this addition just to fit in. > # Since: 0.14.0 > # > ## > @@ -378,7 +381,7 @@ > '*bps_wr_max_length': 'int', '*iops_max_length': 'int', > '*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int', > '*iops_size': 'int', '*group': 'str', 'cache': > 'BlockdevCacheInfo', > -'write_threshold': 'int' } } > +'write_threshold': 'int', '*dirty-bitmaps': ['BlockDirtyInfo'] } > } > > ## > # @BlockDeviceIoStatus: > @@ -656,6 +659,7 @@ > # > # @dirty-bitmaps: dirty bitmaps information (only present if the > # driver has one or more dirty bitmaps) (Since 2.0) > +# Deprecated in 4.2; see BlockDirtyInfo instead. s/BlockDirtyInfo/BlockDeviceInfo/ With the spelling fix, Reviewed-by: Eric Blake Is this worth squeezing into 4.1, to start the deprecation clock one cycle earlier (on the grounds that the missing information for anonymous nodes is a bug)? Or am I pushing the boundaries too far, where keeping this as 4.2 material remains the best course of action? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
From: Vladimir Sementsov-Ogievskiy
Let's add a possibility to query dirty-bitmaps not only on root nodes.
It is useful when dealing both with snapshots and incremental backups.
Signed-off-by: Vladimir Sementsov-Ogievskiy
[Added deprecation information. --js]
Signed-off-by: John Snow
---
block/qapi.c | 5 +
qapi/block-core.json | 6 +-
qemu-deprecated.texi | 12
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/block/qapi.c b/block/qapi.c
index 917435f022..15f1030264 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -79,6 +79,11 @@ BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
info->backing_file = g_strdup(bs->backing_file);
}
+if (!QLIST_EMPTY(>dirty_bitmaps)) {
+info->has_dirty_bitmaps = true;
+info->dirty_bitmaps = bdrv_query_dirty_bitmaps(bs);
+}
+
info->detect_zeroes = bs->detect_zeroes;
if (blk && blk_get_public(blk)->throttle_group_member.throttle_state) {
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 0d43d4f37c..9210ae233d 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -360,6 +360,9 @@
# @write_threshold: configured write threshold for the device.
# 0 if disabled. (Since 2.3)
#
+# @dirty-bitmaps: dirty bitmaps information (only present if node
+# has one or more dirty bitmaps) (Since 4.2)
+#
# Since: 0.14.0
#
##
@@ -378,7 +381,7 @@
'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
'*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
'*iops_size': 'int', '*group': 'str', 'cache': 'BlockdevCacheInfo',
-'write_threshold': 'int' } }
+'write_threshold': 'int', '*dirty-bitmaps': ['BlockDirtyInfo'] } }
##
# @BlockDeviceIoStatus:
@@ -656,6 +659,7 @@
#
# @dirty-bitmaps: dirty bitmaps information (only present if the
# driver has one or more dirty bitmaps) (Since 2.0)
+# Deprecated in 4.2; see BlockDirtyInfo instead.
#
# @io-status: @BlockDeviceIoStatus. Only present if the device
# supports it and the VM is configured to stop on errors
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index c90b08d553..6374b66546 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -134,6 +134,18 @@ The ``status'' field of the ``BlockDirtyInfo'' structure,
returned by
the query-block command is deprecated. Two new boolean fields,
``recording'' and ``busy'' effectively replace it.
+@subsection query-block result field dirty-bitmaps (Since 4.2)
+
+The ``dirty-bitmaps`` field of the ``BlockInfo`` structure, returned by
+the query-block command is itself now deprecated. The ``dirty-bitmaps``
+field of the ``BlockDeviceInfo`` struct should be used instead, which is the
+type of the ``inserted`` field in query-block replies, as well as the
+type of array items in query-named-block-nodes.
+
+Since the ``dirty-bitmaps`` field is optionally present in both the old and
+new locations, clients must use introspection to learn where to anticipate
+the field if/when it does appear in command output.
+
@subsection query-cpus (since 2.12.0)
The ``query-cpus'' command is replaced by the ``query-cpus-fast'' command.
--
2.21.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
