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 <mre...@redhat.com>
> ---
> 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 <ebl...@redhat.com> -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
