From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtMSQ-0007ES-R9 for qemu-devel@nongnu.org; Tue, 25 Nov 2014 15:11:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtMSL-0004Md-QL for qemu-devel@nongnu.org; Tue, 25 Nov 2014 15:11:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtMSL-0004MP-JK for qemu-devel@nongnu.org; Tue, 25 Nov 2014 15:11:25 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPKBOjh002163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 25 Nov 2014 15:11:24 -0500 Message-ID: <5474E26B.70805@redhat.com> Date: Tue, 25 Nov 2014 13:11:23 -0700 From: Eric Blake MIME-Version: 1.0 References: <1416822200-31088-1-git-send-email-mreitz@redhat.com> <1416822200-31088-4-git-send-email-mreitz@redhat.com> In-Reply-To: <1416822200-31088-4-git-send-email-mreitz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oWrwkh8TTkduM0W7vLdcnQO1jAJEkxdRp" Subject: Re: [Qemu-devel] [PATCH v3 3/5] block: Relative backing file for image creation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oWrwkh8TTkduM0W7vLdcnQO1jAJEkxdRp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 backin= g > file has to be opened for determining its size (in case the size has no= t > been explicitly specified) its filename should be interpreted relative > to the new image's base directory and not relative to qemu's working > directory. >=20 > Signed-off-by: Max Reitz > --- > block.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) >=20 > 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, cons= t char *fmt, > if (size =3D=3D -1) { > if (backing_file) { > BlockDriverState *bs; > + char *full_backing =3D 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 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --oWrwkh8TTkduM0W7vLdcnQO1jAJEkxdRp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUdOJrAAoJEKeha0olJ0NqGlgIAIoO6+nMKN6i38zNDUzr2AkS 46mi6YMUr5nSgeUuhTP5rinxWi6cbOqY9L02NGQJ/U0KQWFpCjiJhxjzKau+rvMD E2crIEcB+zVCY1jgA7iQLM0PLYiZ8DyyQoHKBXSFiFEhLUCU+cHqwbB0yavvIi0P vLigRcp1bh7QeL5VBXGDqtYgXuKp2Pgak75OoO2sXnwbvD6KBP5BWs5W8qMGZGnR 6Viwh3P4Dr0+bTe1PybVRhvUkXp18/OpVZ8UPABYMR1KyxlEdK1hFDtDtb2BAwhg A4NeOC2kgHuyTW7ka6NcEOEC8yYTR6Im8tzvdJ+ZKhWap/Q3mXciNYCcTtvgOlc= =VaP1 -----END PGP SIGNATURE----- --oWrwkh8TTkduM0W7vLdcnQO1jAJEkxdRp--