qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block: fix backing file segfault


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH] block: fix backing file segfault
Date: Fri, 10 Jan 2014 18:27:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 09.01.2014 11:59, Kevin Wolf wrote:
[ CCing Max, who was recently active in this area, for another opinion ]

Am 08.01.2014 um 20:43 hat Peter Feiner geschrieben:
When a backing file is opened such that (1) a protocol is directly
used as the block driver and (2) the block driver has bdrv_file_open,
bdrv_open_backing_file segfaults. The problem arises because
bdrv_open_common returns without setting bd->backing_hd->file.

To effect (1), you seem to have to use the -F flag in qemu-img. There
are several block drivers that satisfy (2), such as "file" and "nbd".
Here are some concrete examples:

     #!/bin/bash

     echo Test file format
     ./qemu-img create -f file base.file 1m
     ./qemu-img create -f qcow2 -F file -o backing_file=base.file\
         file-overlay.qcow2
     ./qemu-img convert -O raw file-overlay.qcow2 file-convert.raw

     echo Test nbd format
     SOCK=$PWD/nbd.sock
     ./qemu-img create -f raw base.raw 1m
     ./qemu-nbd -t -k $SOCK base.raw &
     trap "kill $!" EXIT
     while ! test -e $SOCK; do sleep 1; done
     ./qemu-img create -f qcow2 -F nbd -o backing_file=nbd:unix:$SOCK\
         nbd-overlay.qcow2
     ./qemu-img convert -O raw nbd-overlay.qcow2 nbd-convert.raw

Without this patch, the two qemu-img convert commands segfault.

This is a regression that was introduced in v1.7 by
dbecebddfa4932d1c83915bcb9b5ba5984eb91be.

Signed-off-by: Peter Feiner <address@hidden>
---
  block.c |    5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index 64e7d22..a4a172d 100644
--- a/block.c
+++ b/block.c
@@ -1016,8 +1016,9 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict 
*options, Error **errp)
          error_free(local_err);
          return ret;
      }
-    pstrcpy(bs->backing_file, sizeof(bs->backing_file),
-            bs->backing_hd->file->filename);
+    if (bs->backing_hd->file)
+        pstrcpy(bs->backing_file, sizeof(bs->backing_file),
+                bs->backing_hd->file->filename);
      return 0;
  }
I think if there is no bs->backing_hd->file, we should get the filename
from bs->backing_hd->filename instead of leaving it empty.

In fact, can we always do that or does bs->backing_hd normally lack the
filename? If so, perhaps that is what we need to fix, so we can always
directly use bs->backing_hd->filename here.

bs->backing_hd->filename would be set by the bdrv_open_common() in bdrv_open(), the filename is read from file->filename (if file != NULL; in this case, that would be bs->backing_hd->file->filename) or from the configuration option "filename".

The latter configuration option is not used by bdrv_open_backing_file(), as far as I can see. However, bs->backing_hd->file->filename is exactly the field the old code uses, therefore, using bs->backing_hd->filename directly should not break anything.

However, the patch does something different: If file is NULL, it leaves bs->backing_file unchanged; whereas using bs->backing_hd->filename would in this case result in the value of the "filename" option. I think leaving bs->backing_file unchanged is probably better, unless it is "" and the "filename" option is set.

If we want bs->backing_hd->filename to always point to a valid filename, we'd probably have to copy to contents of bs->backing_file there at some point in time, if it is not valid. But this is exactly a point in code where bs->backing_file is updated, so there'd be no gain if we instead updated bs->backing_hd->filename if necessary and then copied that to bs->backing_file, as long as there is no other place in the code where bs->backing_hd->filename always has to be a valid filename.

Thus, I think the patch is okay, but I'd probably prefer "if (bs->backing_hd->filename[0]) pstrcpy(..., bs->backing_hd->filename);" - although that should not differ from the given patch, unless the "filename" option is set for the backing_hd.


Max



reply via email to

[Prev in Thread] Current Thread [Next in Thread]