From: Eric Blake <eblake@redhat.com>
To: jcody@redhat.com
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] block: make bdrv_find_backing_image compare canonical filenames
Date: Wed, 10 Oct 2012 12:34:34 -0600 [thread overview]
Message-ID: <5075BFBA.8020902@redhat.com> (raw)
In-Reply-To: <5075BE97.1070407@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
On 10/10/2012 12:29 PM, Jeff Cody wrote:
>> That's a LOT of stack space, which risks stack overflow, will mostly be
>> unused, and still doesn't work if you have super-deep hierarchies larger
>> than PATH_MAX. Would you be better off using realpath(,NULL) for its
>> allocating semantics, and then free()ing the results?
>>
>
> That is the main reason I changed it from being a recursive function, to
> an iterative one.
>
> Do we know that realpath(,NULL) behaves the same on all platforms?
Gnulib lists the following platforms as mis-handling NULL:
Mac OS X 10.5, FreeBSD 6.4, OpenBSD 4.4, Solaris 10.
>
> We had a thread back in April that touched on the use of realpath, and
> concerns were raised then that realpath(,NULL) was not necessarily safe
> across all OSes:
>
> https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01417.html
In fact, that message points out an even more insidious portability bug
in your algorithm: on Solaris 10, realpath("relative", buffer) leaves
buffer containing "relative" rather than an absolute name, but your
algorithm depends on matching absolute names. I don't know if we port
qemu to Solaris 10, but it's worth considering my question back in that
thread - does glib provide us a more portable function for converting a
relative name into a canonical path that is guaranteed to work everywhere?
>
> That said, if there is concern over the stack usage, to be safe I can
> manually g_malloc() each array.
g_malloc() would solve the stack size concern, but not the Solaris 10
relative name bug.
--
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: 617 bytes --]
next prev parent reply other threads:[~2012-10-10 18:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-10 5:56 [Qemu-devel] [PATCH 0/2] block-commit fixes Jeff Cody
2012-10-10 5:56 ` [Qemu-devel] [PATCH 1/2] block: make bdrv_find_backing_image compare canonical filenames Jeff Cody
2012-10-10 7:34 ` Paolo Bonzini
2012-10-10 7:59 ` Jeff Cody
2012-10-10 8:07 ` Paolo Bonzini
2012-10-10 18:13 ` Eric Blake
2012-10-10 18:29 ` Jeff Cody
2012-10-10 18:34 ` Eric Blake [this message]
2012-10-10 18:57 ` Jeff Cody
2012-10-10 19:15 ` Eric Blake
2012-10-12 21:52 ` Eric Blake
2012-10-13 15:25 ` Jeff Cody
2012-10-16 11:40 ` Kevin Wolf
2012-10-10 5:56 ` [Qemu-devel] [PATCH 2/2] block: in commit, determine base image from the top image Jeff Cody
2012-10-10 7:35 ` Paolo Bonzini
2012-10-10 18:18 ` Eric Blake
2012-10-11 15:36 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5075BFBA.8020902@redhat.com \
--to=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.