RE: [PATCH v3] migration: Don't allow migration if vm is in POSTMIGRATE

Ping. It seems no one handle this patch. > -Original Message- > From: Pankaj Gupta [mailto:pankaj.gupta.li...@gmail.com] > Sent: Wednesday, December 09, 2020 10:21 PM > To: tuguoyi (Cloud) > Cc: Juan Quintela ; Dr. David Alan Gilbert > ; vsement...@virtuozzo

[PATCH 1/2] savevm: Remove dead code in save_snapshot()

The snapshot in each bs is deleted at the beginning, so there is no need to find the snapshot again. Signed-off-by: Tuguoyi --- migration/savevm.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/migration/savevm.c b/migration/savevm.c index 5f937a2..601b514 100644

[PATCH 2/2] savevm: Delete snapshots just created in case of error

bdrv_all_create_snapshot() can fails with some snapshots created, so it's better to delete those snapshots before returns to the caller Signed-off-by: Tuguoyi --- migration/savevm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/migration/savevm.c b/migration/savevm.c index 601b514

[PATCH 0/2] savevm: Delete stale snapshots in save_snapshot()

These two patches just clear dead code and delete stale snapshots in case of error in save_snapshot() Tuguoyi (2): savevm: Remove dead code in save_snapshot() savevm: Delete snapshots just created in case of error migration/savevm.c | 11 +++ 1 file changed, 3 insertions(+), 8

[PATCH v3] migration: Don't allow migration if vm is in POSTMIGRATE

all(), and during the second migration the bdrv_inactivate_recurse assert that the bs->open_flags is already BDRV_O_INACTIVE enabled which cause crash. As Vladimir suggested, this patch makes migrate_prepare check the state of vm and return error if it is in RUN_STATE_POSTMIGRATE state. Signed-off-by: T

RE: [PATCH v2] migration: Don't allow migration if vm is in POSTMIGRATE state

On December 07, 2020 6:06 PM Vladimir Sementsov-Ogievskiy wrote: > 07.12.2020 10:44, Tuguoyi wrote: > > The following steps will cause qemu assertion failure: > > - pause vm by executing 'virsh suspend' > > - create external snapshot of memory and disk using 'vi

[PATCH v2] migration: Don't allow migration if vm is in POSTMIGRATE state

Signed-off-by: Tuguoyi --- migration/migration.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/migration/migration.c b/migration/migration.c index 87a9b59..4091678 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -3622,6 +3622,13 @@ void migrate_fd_connect(MigrationSt

RE: [PATCH] block: Don't inactivate bs if it is aleady inactive

> -Original Message- > From: Vladimir Sementsov-Ogievskiy [mailto:vsement...@virtuozzo.com] > Sent: Saturday, November 28, 2020 4:48 PM > To: tuguoyi (Cloud) ; Kevin Wolf ; > Max Reitz ; qemu-bl...@nongnu.org > Cc: qemu-devel@nongnu.org; wangyong (Cloud) > Subje

RE: [PATCH] block: Don't inactivate bs if it is aleady inactive

crash. > > This patch just make the bdrv_inactivate_all() to don't inactivate the bs if > it is > already inactive > > Signed-off-by: Tuguoyi > --- > block.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/block.c b/block.c &

[PATCH] block: Don't inactivate bs if it is aleady inactive

ion the bdrv_inactivate_recurse assert that the bs->open_flags is already BDRV_O_INACTIVE enabled which cause crash. This patch just make the bdrv_inactivate_all() to don't inactivate the bs if it is already inactive Signed-off-by: Tuguoyi --- block.c | 7 ++- 1 file changed, 6 insertions

RE: [PATCH] block: Fix integer promotion error in bdrv_getlength()

On Wed, 2019-07-03 at 10:13 -0500, Eric Blake wrote: > On 11/5/20 2:31 AM, Max Reitz wrote: > > On 05.11.20 06:40, Tuguoyi wrote: > >> As BDRV_SECTOR_SIZE is of type uint64_t, the expression will > >> automatically convert the @ret to uint64_t. When an error code > &g

RE: [PATCH] block: Return the real error code in bdrv_getlength

Sorry, please ignore this patch, it's not a right fix -- Best regards, Guoyi > -Original Message- > From: tuguoyi (Cloud) > Sent: Thursday, November 05, 2020 11:11 AM > To: 'Kevin Wolf' ; 'Max Reitz' ; > 'qemu-bl...@nongnu.org' > Cc: 'qemu-devel@nongnu.org' > S

[PATCH] block: Fix integer promotion error in bdrv_getlength()

As BDRV_SECTOR_SIZE is of type uint64_t, the expression will automatically convert the @ret to uint64_t. When an error code returned from bdrv_nb_sectors(), the promoted @ret will be a very large number, as a result the -EFBIG will be returned which is not the real error code. Signed-off-by:

[PATCH] block: Return the real error code in bdrv_getlength

The return code from bdrv_nb_sectors() should be checked before doing the following sanity check. Signed-off-by: Guoyi Tu --- block.c | 4 1 file changed, 4 insertions(+) diff --git a/block.c b/block.c index 430edf7..19ebbc0 100644 --- a/block.c +++ b/block.c @@ -5082,6 +5082,10 @@

[PATCH] qemu-img: Make sure @sn_opts can be deleted in all error cases

@sn_opts is initialized at the beginning, so it should be deleted after jumping to the lable 'fail_getopt' Signed-off-by: Guoyi Tu --- qemu-img.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qemu-img.c b/qemu-img.c index 2103507..229cdf9 100644 --- a/qemu-img.c +++

[PATCH] qcow2-cluster: Fix integer left shift error in qcow2_alloc_cluster_link_l2()

When calculating the offset, the result of left shift operation will be promoted to type int64 automatically because the left operand of + operator is uint64_t. but the result after integer promotion may be produce an error value for us and trigger the following asserting error. For example,

RE: util/async: File descriptor leak in aio_context_unref()?

OK, I got it, it will be released in aio_ctx_finalize(). Please ignore this mail. > -Original Message- > From: tuguoyi (Cloud) > Sent: Sunday, January 19, 2020 4:15 PM > To: 'Stefan Hajnoczi' ; 'Fam Zheng' > ; 'qemu-bl...@nongnu.org' > Cc: 'qemu-devel@nongnu.org' ;

util/async: File descriptor leak in aio_context_unref()?

In aio_context_new(), the @notifier variable will be initialized, but it don't get cleaned up in aio_context_unref() when reference count reaches to 0, it will cause file descriptor leak. -- Best regards, Guoyi

[PATCH v2] qcow2: Move error check of local_err near its assignment

The local_err check outside of the if block was necessary when it was introduced in commit d1258dd0c87 because it needed to be executed even if qcow2_load_autoloading_dirty_bitmaps() returned false. After some modifications that all required the error check to remain where it is, commit

RE: [PATCH] qcow2: Move error check of local_err near its assignment

On 18.12.2019 17:33 Kevin Wolf wrote: > > Am 18.12.2019 um 03:26 hat Tuguoyi geschrieben: > > > > Signed-off-by: Guoyi Tu > > Empty commit messages are rarely acceptable. You should explain here why > you are making the change and why it's correct (for examp

[PATCH] qcow2: Move error check of local_err near its assignment

Signed-off-by: Guoyi Tu --- block/qcow2.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/block/qcow2.c b/block/qcow2.c index 7c18721..ce3db29 100644 --- a/block/qcow2.c +++ b/block/qcow2.c @@ -1705,14 +1705,14 @@ static int coroutine_fn

RE: [PATCH v4] qcow2-bitmap: Fix uint64_t left-shift overflow

On 01.11.2019 18:09, Vladimir Sementsov-Ogievskiy wrote: > 01.11.2019 12:34, Tuguoyi wrote: > > On 01.11.2019 17:25 Vladimir Sementsov-Ogievskiy wrote: > >> 01.11.2019 10:37, Tuguoyi wrote: > >>> There are two issues in In check_constraints_on_bitmap(), > >>&

RE: [PATCH v4] qcow2-bitmap: Fix uint64_t left-shift overflow

On 01.11.2019 17:25 Vladimir Sementsov-Ogievskiy wrote: > 01.11.2019 10:37, Tuguoyi wrote: > > There are two issues in In check_constraints_on_bitmap(), > > 1) The sanity check on the granularity will cause uint64_t integer > > left-shift overflow when cluster_size is 2

[PATCH v4] qcow2-bitmap: Fix uint64_t left-shift overflow

There are two issues in In check_constraints_on_bitmap(), 1) The sanity check on the granularity will cause uint64_t integer left-shift overflow when cluster_size is 2M and the granularity is BIGGER than 32K. 2) The way to calculate image size that the maximum bitmap supported can map to is a bit

[PATCH v3] qcow2-bitmap: Fix uint64_t left-shift overflow

There are two issues in In check_constraints_on_bitmap(), 1) The sanity check on the granularity will cause uint64_t integer left-shift overflow when cluster_size is 2M and the granularity is BIGGER than 32K. 2) The way to calculate image size that the maximum bitmap supported can map to is a bit

RE: [PATCH v2] qcow2-bitmap: Fix uint64_t left-shift overflow

On 29.10.2019 19:57 Vladimir Sementsov-Ogievskiy wrote: > 29.10.2019 14:14, Max Reitz wrote: > > On 28.10.19 07:33, Tuguoyi wrote: > >> In check_constraints_on_bitmap(), the sanity check on the granularity > >> will cause uint64_t integer left-shift overflow w

[PATCH v2] qcow2-bitmap: Fix uint64_t left-shift overflow

In check_constraints_on_bitmap(), the sanity check on the granularity will cause uint64_t integer left-shift overflow when cluster_size is 2M and the granularity is BIGGER than 32K. As a result, for a qcow2 disk with cluster_size set to 2M, we could not even create a dirty bitmap with default

[PATCH] qcow2-bitmap: Fix uint64_t left-shift overflow

In check_constraints_on_bitmap(), the sanity check on the granularity will cause uint64_t integer left-shift overflow when cluster_size is 2M and the granularity is bigger than 32K which is even smaller than the default value for a qcow2 disk with cluster_size set to 64k or bigger. This patch fix