qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence
@ 2013-09-30 15:57 Max Reitz
  2013-09-30 17:48 ` Eric Blake
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Max Reitz @ 2013-09-30 15:57 UTC (permalink / raw)
  To: qemu-devel; +Cc: Kevin Wolf, Stefan Hajnoczi, Max Reitz

Switching the L1 table in memory should be an atomic operation, as far
as possible. Calling qcow2_free_clusters on the old L1 table on disk is
not a good idea when the old L1 table is no longer valid and the address
to the new one hasn't yet been written into the corresponding
BDRVQcowState field. To be more specific, this can lead to segfaults due
to qcow2_check_metadata_overlap trying to access the L1 table during the
free operation.

Signed-off-by: Max Reitz <mreitz@redhat.com>
---
 block/qcow2-cluster.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 72cb573..0fd26bb 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -35,6 +35,7 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
     BDRVQcowState *s = bs->opaque;
     int new_l1_size2, ret, i;
     uint64_t *new_l1_table;
+    int64_t old_l1_table_offset, old_l1_size;
     int64_t new_l1_table_offset, new_l1_size;
     uint8_t data[12];
 
@@ -106,11 +107,13 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
         goto fail;
     }
     g_free(s->l1_table);
-    qcow2_free_clusters(bs, s->l1_table_offset, s->l1_size * sizeof(uint64_t),
-                        QCOW2_DISCARD_OTHER);
+    old_l1_table_offset = s->l1_table_offset;
     s->l1_table_offset = new_l1_table_offset;
     s->l1_table = new_l1_table;
+    old_l1_size = s->l1_size;
     s->l1_size = new_l1_size;
+    qcow2_free_clusters(bs, old_l1_table_offset, old_l1_size * sizeof(uint64_t),
+                        QCOW2_DISCARD_OTHER);
     return 0;
  fail:
     g_free(new_l1_table);
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence
  2013-09-30 15:57 [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence Max Reitz
@ 2013-09-30 17:48 ` Eric Blake
  2013-10-01  9:12 ` Kevin Wolf
  2013-10-02 13:38 ` Stefan Hajnoczi
  2 siblings, 0 replies; 4+ messages in thread
From: Eric Blake @ 2013-09-30 17:48 UTC (permalink / raw)
  To: Max Reitz; +Cc: Kevin Wolf, qemu-devel, Stefan Hajnoczi

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On 09/30/2013 09:57 AM, Max Reitz wrote:
> Switching the L1 table in memory should be an atomic operation, as far
> as possible. Calling qcow2_free_clusters on the old L1 table on disk is
> not a good idea when the old L1 table is no longer valid and the address
> to the new one hasn't yet been written into the corresponding
> BDRVQcowState field. To be more specific, this can lead to segfaults due
> to qcow2_check_metadata_overlap trying to access the L1 table during the
> free operation.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
>  block/qcow2-cluster.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence
  2013-09-30 15:57 [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence Max Reitz
  2013-09-30 17:48 ` Eric Blake
@ 2013-10-01  9:12 ` Kevin Wolf
  2013-10-02 13:38 ` Stefan Hajnoczi
  2 siblings, 0 replies; 4+ messages in thread
From: Kevin Wolf @ 2013-10-01  9:12 UTC (permalink / raw)
  To: Max Reitz; +Cc: qemu-devel, Stefan Hajnoczi

Am 30.09.2013 um 17:57 hat Max Reitz geschrieben:
> Switching the L1 table in memory should be an atomic operation, as far
> as possible. Calling qcow2_free_clusters on the old L1 table on disk is
> not a good idea when the old L1 table is no longer valid and the address
> to the new one hasn't yet been written into the corresponding
> BDRVQcowState field. To be more specific, this can lead to segfaults due
> to qcow2_check_metadata_overlap trying to access the L1 table during the
> free operation.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>

Reviewed-by: Kevin Wolf <kwolf@redhat.com>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence
  2013-09-30 15:57 [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence Max Reitz
  2013-09-30 17:48 ` Eric Blake
  2013-10-01  9:12 ` Kevin Wolf
@ 2013-10-02 13:38 ` Stefan Hajnoczi
  2 siblings, 0 replies; 4+ messages in thread
From: Stefan Hajnoczi @ 2013-10-02 13:38 UTC (permalink / raw)
  To: Max Reitz; +Cc: Kevin Wolf, qemu-devel, Stefan Hajnoczi

On Mon, Sep 30, 2013 at 05:57:21PM +0200, Max Reitz wrote:
> Switching the L1 table in memory should be an atomic operation, as far
> as possible. Calling qcow2_free_clusters on the old L1 table on disk is
> not a good idea when the old L1 table is no longer valid and the address
> to the new one hasn't yet been written into the corresponding
> BDRVQcowState field. To be more specific, this can lead to segfaults due
> to qcow2_check_metadata_overlap trying to access the L1 table during the
> free operation.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
>  block/qcow2-cluster.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-10-02 13:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-30 15:57 [Qemu-devel] [PATCH] qcow2: Switch L1 table in a single sequence Max Reitz
2013-09-30 17:48 ` Eric Blake
2013-10-01  9:12 ` Kevin Wolf
2013-10-02 13:38 ` Stefan Hajnoczi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).