Memset vhost_dev to zero in the vhost_dev_cleanup function.
This causes dev.vqs to be NULL, so that
vqs does not free up space when calling the g_free function.
This will result in a memory leak. But you can't release vqs
directly in the vhost_dev_cleanup function, because vhost_net
will also call
On Mon 17 Dec 2018 11:43:18 PM CET, Max Reitz wrote:
> @@ -3327,6 +,7 @@ static int img_rebase(int argc, char **argv)
> qdict_put_bool(options, BDRV_OPT_FORCE_SHARE, true);
> }
>
> +bdrv_refresh_filename(bs);
> overlay_filename = bs->exa
There are two bugs in dmg reading.
First, it may hang in binary search. this problem is solved by patch 1.
Second, because of lacking zero chunk table, reading zero sector will
return EIO. thie problem is solved by patch 2 and 3.
Thanks
v1 - >v2:
* fix typos in patch 1
* add patch 2 and patch 3
Signed-off-by: yuchenlin
---
block/dmg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/dmg.c b/block/dmg.c
index 0e05702f5d..6b0a057bf8 100644
--- a/block/dmg.c
+++ b/block/dmg.c
@@ -267,7 +267,7 @@ static int dmg_read_mish_block(BDRVDMGState *s,
DmgHeaderState *d
There is a possible hang in original binary search implementation. That is
if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case.
The chunk1 will be still 4, and so on.
Signed-off-by: yuchenlin
---
block/dmg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/
The dmg file has many tables which describe: "start from sector XXX to
sector XXX, the compression method is XXX and where the compressed data
resides on".
Each sector in the expanded file should be covered by a table. The table
will describe the offset of compressed data (or raw depends on the ty
