Patchew URL:
https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [RFC v5 000/126] error: auto propagated local_err
Type: series
Message-id:
Patchew URL:
https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
On 10/11/19 8:18 AM, Max Reitz wrote:
> For long test image paths, the order of the "Formatting" line and the
> "(qemu)" prompt after a drive_backup HMP command may be reversed. In
> fact, the interaction between the prompt and the line may lead to the
> "Formatting" to being greppable at all
On 10/4/19 11:39 AM, Max Reitz wrote:
> On 18.09.19 01:45, John Snow wrote:
>> This series uses python logging to enable output conditionally on
>> iotests.log(). We unify an initialization call (which also enables
>> debugging output for those tests with -d) and then make the switch
>> inside
On 10/11/19 5:48 PM, Eric Blake wrote:
> On 10/11/19 4:25 PM, John Snow wrote:
>> From: Vladimir Sementsov-Ogievskiy
>>
>> hbitmap_reset has an unobvious property: it rounds requested region up.
>> It may provoke bugs, like in recently fixed write-blocking mode of
>> mirror: user calls reset
On 10/11/19 3:55 PM, Kevin Wolf wrote:
Instead of parsing help options as normal object properties and
returning an error, provide the same help functionality as the system
emulator in qemu-img, too.
Signed-off-by: Kevin Wolf
---
qemu-img.c | 34 +-
1 file
On 10/11/19 3:55 PM, Kevin Wolf wrote:
Printing help for --object is something that we don't only want in the
s/don't/not/
system emulator, but also in tools that support --object. Move it into a
separate function in qom/object_interfaces.c to make the code accessible
for tools.
On 10/11/19 4:25 PM, John Snow wrote:
From: Vladimir Sementsov-Ogievskiy
hbitmap_reset has an unobvious property: it rounds requested region up.
It may provoke bugs, like in recently fixed write-blocking mode of
mirror: user calls reset on unaligned region, not keeping in mind that
there are
On 10/11/19 3:55 PM, Kevin Wolf wrote:
Instead of parsing help options as normal object properties and
returning an error, provide the same help functionality as the system
emulator in qemu-io, too.
Signed-off-by: Kevin Wolf
---
qemu-io.c | 9 -
1 file changed, 8 insertions(+), 1
On 10/11/19 3:55 PM, Kevin Wolf wrote:
Instead of parsing help options as normal object properties and
returning an error, provide the same help functionality as the system
emulator in qemu-nbd, too.
Signed-off-by: Kevin Wolf
---
qemu-nbd.c | 9 -
1 file changed, 8 insertions(+), 1
This parameter has been deprecated since 2.12.0 and is eligible for
removal. Remove this parameter as it is actually completely ignored;
let's not give false hope.
Signed-off-by: John Snow
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-id:
From: Vladimir Sementsov-Ogievskiy
Reopening bitmaps to RW was broken prior to previous commit. Check that
it works now.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20190927122355.7344-4-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
tests/qemu-iotests/165 | 57
From: Vladimir Sementsov-Ogievskiy
qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all
readonly. But the latter don't work, as
qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing.
It's OK for inactivation but bad idea for reopen-ro. And this leads to
the
From: Vladimir Sementsov-Ogievskiy
The only reason I can imagine for this strange code at the very-end of
bdrv_reopen_commit is the fact that bs->read_only updated after
calling drv->bdrv_reopen_commit in bdrv_reopen_commit. And in the same
time, prior to previous commit, qcow2_reopen_bitmaps_rw
I already try to make sure all bitmaps patches have been reviewed by both
Red Hat and Virtuozzo anyway, so this formalizes the arrangement.
Fam meanwhile is no longer as active, so I am removing him as a co-maintainer
simply to reflect the current practice.
Signed-off-by: John Snow
Reviewed-by:
From: Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20190927122355.7344-8-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
tests/qemu-iotests/260 | 89 ++
tests/qemu-iotests/260.out | 52 ++
From: Vladimir Sementsov-Ogievskiy
- Correct check for write access to file child, and in correct place
(only if we want to write).
- Support reopen rw -> rw (which will be used in following commit),
for example, !bdrv_dirty_bitmap_readonly() is not a corruption if
bitmap is marked IN_USE
From: Vladimir Sementsov-Ogievskiy
It's needed to fix reopening qcow2 with bitmaps to RW. Currently it
can't work, as qcow2 needs write access to file child, to mark bitmaps
in-image with IN_USE flag. But usually children goes after parents in
reopen queue and file child is still RO on qcow2
From: Vladimir Sementsov-Ogievskiy
bdrv_dirty_bitmap_next is always used in same pattern. So, split it
into _next and _first, instead of combining two functions into one and
add FOR_EACH_DIRTY_BITMAP macro.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id:
From: Vladimir Sementsov-Ogievskiy
Firstly, no reason to optimize failure path. Then, function name is
ambiguous: it checks for readonly and similar things, but someone may
think that it will ignore normal bitmaps which was just unchanged, and
this is in bad relation with the fact that we should
From: Vladimir Sementsov-Ogievskiy
The function is unused, drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190927122355.7344-6-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
block/qcow2.h| 2 --
block/qcow2-bitmap.c | 15
From: Vladimir Sementsov-Ogievskiy
Add bs field to BdrvDirtyBitmap structure. Drop BlockDriverState
parameter from bitmap APIs where possible.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190916141911.5255-3-vsement...@virtuozzo.com
Signed-off-by: John Snow
From: Vladimir Sementsov-Ogievskiy
mutex field is just a pointer to bs->dirty_bitmap_mutex, so no needs
to store it in BdrvDirtyBitmap when we have bs pointer in it (since
previous patch).
Drop mutex field. Constantly use bdrv_dirty_bitmaps_lock/unlock in
block/dirty-bitmap.c to make it more
From: Vladimir Sementsov-Ogievskiy
Drop meta bitmaps, as they are unused.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190916141911.5255-2-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
include/block/dirty-bitmap.h | 5
block/dirty-bitmap.c
From: Vladimir Sementsov-Ogievskiy
It's more comfortable to not deal with local_err.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190920082543.23444-3-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
block/qcow2.h| 5 ++---
From: Vladimir Sementsov-Ogievskiy
We'll need reverse-foreach in the following commit, QTAILQ support it,
so move to QTAILQ.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
Message-id: 20190927122355.7344-2-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
From: Vladimir Sementsov-Ogievskiy
qmp_block_dirty_bitmap_add and do_block_dirty_bitmap_remove do acquire
aio context since 0a6c86d024c52b. But this is not enough: we also must
lock qcow2 mutex when access in-image metadata. Especially it concerns
freeing qcow2 clusters.
To achieve this, move
From: Vladimir Sementsov-Ogievskiy
hbitmap_reset has an unobvious property: it rounds requested region up.
It may provoke bugs, like in recently fixed write-blocking mode of
mirror: user calls reset on unaligned region, not keeping in mind that
there are possible unrelated dirty bytes, covered
From: Vladimir Sementsov-Ogievskiy
block/dirty-bitmap.c seems to be more appropriate for it and
bdrv_remove_persistent_dirty_bitmap already in it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190920082543.23444-2-vsement...@virtuozzo.com
Signed-off-by: John
The following changes since commit 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d:
Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into
staging (2019-10-08 16:08:35 +0100)
are available in the Git repository at:
https://github.com/jnsnow/qemu.git tags/bitmaps-pull-request
Instead of parsing help options as normal object properties and
returning an error, provide the same help functionality as the system
emulator in qemu-nbd, too.
Signed-off-by: Kevin Wolf
---
qemu-nbd.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/qemu-nbd.c
Instead of parsing help options as normal object properties and
returning an error, provide the same help functionality as the system
emulator in qemu-io, too.
Signed-off-by: Kevin Wolf
---
qemu-io.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/qemu-io.c
Instead of parsing help options as normal object properties and
returning an error, provide the same help functionality as the system
emulator in qemu-img, too.
Signed-off-by: Kevin Wolf
---
qemu-img.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
Printing help for --object is something that we don't only want in the
system emulator, but also in tools that support --object. Move it into a
separate function in qom/object_interfaces.c to make the code accessible
for tools.
Signed-off-by: Kevin Wolf
---
include/qom/object_interfaces.h | 12
This series fixes that the tools don't consider help options for
--object and just treat them as regular object properties. For example:
$ ./qemu-io --object secret,help
qemu-io: Parameter 'id' is missing
With these patches, we get the expected behaviour like in the system
emulator.
On 10/11/19 6:02 AM, Vladimir Sementsov-Ogievskiy wrote:
> 10.10.2019 21:46, John Snow wrote:
>>
>>
>> On 10/10/19 11:39 AM, Eric Blake wrote:
>>> On 6/7/19 1:53 PM, Vladimir Sementsov-Ogievskiy wrote:
07.06.2019 21:48, Vladimir Sementsov-Ogievskiy wrote:
>
On 10/11/19 5:12 AM, Peter Krempa wrote:
> On Thu, Oct 10, 2019 at 14:08:12 -0400, John Snow wrote:
>> On 10/10/19 7:54 AM, Peter Krempa wrote:
>>> On Thu, Oct 10, 2019 at 13:42:26 +0200, Philippe Mathieu-Daudé wrote:
On 10/10/19 1:26 PM, Peter Krempa wrote:
>
> [...]
>
>>> To be honest,
Am 11.10.2019 um 22:05 hat Cleber Rosa geschrieben:
> On Fri, Oct 11, 2019 at 02:27:25PM +0300, Nir Soffer wrote:
> > On Fri, Oct 11, 2019, 12:36 Kevin Wolf wrote:
> >
> > > Am 09.10.2019 um 21:47 hat Cleber Rosa geschrieben:
> > > > Due to not being able to find a reason to have shebangs on
On Fri, Oct 11, 2019 at 02:27:25PM +0300, Nir Soffer wrote:
> On Fri, Oct 11, 2019, 12:36 Kevin Wolf wrote:
>
> > Am 09.10.2019 um 21:47 hat Cleber Rosa geschrieben:
> > > Due to not being able to find a reason to have shebangs on files that
> > > are not executable.
> > >
> > > While at it, add
On 10/11/19 11:05 AM, Vladimir Sementsov-Ogievskiy wrote:
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint()
On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint()
On 10/11/19 9:22 AM, Guoheyi wrote:
> Hi folks,
>
> We observed Linux on VM occasionally (at very low rate) got soft lockup
> when a remote cdrom is attached. The guest hangs up at below call trace:
>
That's certainly a new one to me :)
> [Tue Oct8 23:02:53 2019]ata_scsi_queuecmd+0xe0/0x2a0
On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
scripts/coccinelle/auto-propagated-errp.cocci | 118 ++
1 file changed, 118 insertions(+)
create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
diff
On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/snapshot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Eric Blake
diff --git a/block/snapshot.c b/block/snapshot.c
index 8081616ae9..bd9fb01817
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/snapshot.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Eric Blake
diff --git a/include/block/snapshot.h b/include/block/snapshot.h
index
On 10/11/19 12:12 PM, Eric Blake wrote:
On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
+@@
+identifier rule1.fn;
+identifier rule1.local_err;
+@@
+
+ fn(...)
+ {
+ <...
+(
+- error_free(local_err);
+- local_err = NULL;
++
> -Original Message-
> From: Lukas Straub
> Sent: Saturday, October 12, 2019 12:01 AM
> To: Zhang, Chen
> Cc: qemu-devel ; Jason Wang
> ; Wen Congyang ;
> Xie Changlong ; Kevin Wolf
> ; Max Reitz ; qemu-block
>
> Subject: Re: [PATCH v6 4/4] colo: Update Documentation for continuous
>
On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
At the request of Markus: full version of errp propagation. Let's look
at it. Cover as much as possible, except inserting macro invocation
where it's not necessary.
It's huge, and so it's an RFC.
Is there a repo containing
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
CC: Gerd Hoffmann
CC: "Gonglei (Arei)"
CC: Eduardo Habkost
CC: Igor Mammedov
CC: Laurent Vivier
CC: Amit Shah
CC: Kevin Wolf
CC: Max Reitz
CC: John Snow
CC: Ari Sundholm
CC: Pavel Dovgalyuk
CC: Paolo Bonzini
CC: Stefan Hajnoczi
CC: Fam
Add script to automatically commit tree-wide changes per-subsystem.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
CC: Gerd Hoffmann
CC: "Gonglei (Arei)"
CC: Eduardo Habkost
CC: Igor Mammedov
CC: Laurent Vivier
CC: Amit Shah
CC: Kevin Wolf
CC: Max Reitz
CC: John Snow
CC: Ari Sundholm
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote:
Make nbd_iter_channel_error errp handler well formed:
rename errp to errp_in, as it is IN-parameter here (which is unusual
Actually, rename local_err to errp_in.
for errp).
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
Hi all!
At the request of Markus: full version of errp propagation. Let's look
at it. Cover as much as possible, except inserting macro invocation
where it's not necessary.
It's huge, and so it's an RFC.
In v5 I've added a lot more preparation cleanups:
01-23 are preparation cleanups
01: not
On 10/11/19 10:28 AM, Max Reitz wrote:
The user cannot choose which snapshots are removed. This is fine
because we have chosen the maximum snapshot table size to be so large
(65536 entries) that it cannot be reasonably reached. If the snapshot
table exceeds this size, the image has probably
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
On 10/11/19 10:28 AM, Max Reitz wrote:
qcow2 v3 images require every snapshot table entry to have at least 16
bytes of extra data. If they do not, let qemu-img check -r all fix it.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
block/qcow2-snapshot.c | 18 ++
1 file
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
On 10/11/19 10:28 AM, Max Reitz wrote:
qcow2 v3 requires every snapshot table entry to have two extra data
fields: The 64-bit VM state size, and the virtual disk size. Both are
optional for v2 images, so they may not be present.
qcow2_upgrade() therefore should update the snapshot table to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
On 10/11/19 10:28 AM, Max Reitz wrote:
The qcow2 specification says to ignore unknown extra data fields in
snapshot table entries. Currently, we discard it whenever we update the
image, which is a bit different from "ignore".
This patch makes the qcow2 driver keep all unknown extra data fields
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
On Thu, 10 Oct 2019 10:34:15 +
"Zhang, Chen" wrote:
> > -Original Message-
> > From: Lukas Straub
> > Sent: Wednesday, October 9, 2019 11:17 PM
> > To: Zhang, Chen
> > Cc: qemu-devel ; Jason Wang
> > ; Wen Congyang ;
> > Xie Changlong ; Kevin Wolf
> > ; Max Reitz ; qemu-block
> >
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal & error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
error_setg earlier than information
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/snapshot.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/block/snapshot.h b/include/block/snapshot.h
index b5d5084a12..2bfcd57578 100644
--- a/include/block/snapshot.h
+++ b/include/block/snapshot.h
@@
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
Make nbd_iter_channel_error errp handler well formed:
rename errp to errp_in, as it is IN-parameter here (which is unusual
for errp).
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/nbd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/nbd.c
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/snapshot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/snapshot.c b/block/snapshot.c
index 8081616ae9..bd9fb01817 100644
--- a/block/snapshot.c
+++ b/block/snapshot.c
@@ -426,7 +426,7 @@ fail:
}
int
Add a test how our qcow2 driver handles extra data in snapshot table
entries, and how it repairs overly long snapshot tables.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
tests/qemu-iotests/261 | 523 +
tests/qemu-iotests/261.out | 346
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
tests/qemu-iotests/common.rc | 20
1 file changed, 20 insertions(+)
diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
index 12b4751848..fa7bae2422 100644
--- a/tests/qemu-iotests/common.rc
+++
The user cannot choose which snapshots are removed. This is fine
because we have chosen the maximum snapshot table size to be so large
(65536 entries) that it cannot be reasonably reached. If the snapshot
table exceeds this size, the image has probably been corrupted in some
way; in this case,
qcow2 v3 images require every snapshot table entry to have at least 16
bytes of extra data. If they do not, let qemu-img check -r all fix it.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
block/qcow2-snapshot.c | 18 ++
1 file changed, 18 insertions(+)
diff --git
When repairing the snapshot table, we truncate entries that have too
much extra data. This frees up space that we do not have to count
towards the snapshot table size.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
block/qcow2-snapshot.c | 14 +-
1 file changed, 13
1 - 100 of 166 matches
Mail list logo
