Re: [Qemu-devel] [PATCH v3 3/5] block: Relative backing file for image creation

[Eric Blake]

On 11/24/2014 02:43 AM, Max Reitz wrote:
> Relative backing filenames are always relative to the backed image's
> directory; the same applies to image creation. Therefore, if the backing
> file has to be opened for determining its size (in case the size has not
> been explicitly specified) its filename should be interpreted relative
> to the new image's base directory and not relative to qemu's working
> directory.
> 
> Signed-off-by: Max Reitz <address@hidden>
> ---
>  block.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/block.c b/block.c
> index a0cddcd..ed8e187 100644
> --- a/block.c
> +++ b/block.c
> @@ -5633,16 +5633,26 @@ void bdrv_img_create(const char *filename, const char 
> *fmt,
>      if (size == -1) {
>          if (backing_file) {
>              BlockDriverState *bs;
> +            char *full_backing = g_new0(char, PATH_MAX);

PATH_MAX is undefined on GNU Hurd.  But qemu doesn't compile on GNU
Hurd.  Furthermore, Linux allows (relative) paths in deep hierarchies
such that the absolute path is longer than PATH_MAX.  On the other hand,
such usage is rare (in fact, as coreutils learned, if you aren't using
openat() and friends reliably for O(n) descent into such deep
hierarchies, you then suffer from O(n^2) effects that make such paths
painful to create and use in the first place).  Besides, there are
already existing usage sites in qemu capped at PATH_MAX.

Therefore, in spite of all of my rambling, your patch is correct as-is
(I'm NOT asking you to rewrite to something safer that can tolerate
arbitrary filename lengths).

Reviewed-by: Eric Blake <address@hidden>

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

signature.asc
Description: OpenPGP digital signature