All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: Paul Bolle <pebolle@tiscali.nl>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] linux-user: use realpath for emulation dir paths
Date: Fri, 04 Dec 2009 11:00:10 +0100	[thread overview]
Message-ID: <874oo76out.fsf@lechat.rtp-net.org> (raw)
In-Reply-To: <20091204092938.GA23929@kos.to> (Riku Voipio's message of "Fri\, 4 Dec 2009 11\:29\:38 +0200")

Riku Voipio <riku.voipio@iki.fi> writes:

Hi,

> On Fri, Oct 02, 2009 at 02:25:36PM +0200, Paul Bolle wrote:
>> Note that I have some reservations about the current init_paths() and
>> path() code:
>> - their names seem to confusing. Maybe those should be init_base() and
>> base() or something similar;
>> - why does init_paths() copy all filenames in the emulation dir (at
>> least, that what it seems to do)? Try something silly like
>> "-L /home/../" to see what I mean ...
>> - and why does path() return the original filename if that file isn't
>> found in the emulation dir? That looks like a nice source for confusing
>> behavior or crashes, as that means an identical named file (but using
>> the regular root) will then be used.
>
> Yeah, all that is a big mess and should be cleaned up. At the moment it
> is all too easy to get init_paths to recurse forever..

fwiw, it should not be hard to prevent this dead loop. I have somewhere
a patch avoiding going into /dev,/proc and it cured the problem. Of
course, there may be some other places leading to deadloop but at least
avoiding /dev and /proc would be a good start if one really wants to fix
that.

Arnaud

  reply	other threads:[~2009-12-04  9:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02 12:25 [Qemu-devel] [PATCH] linux-user: use realpath for emulation dir paths Paul Bolle
2009-12-04  9:29 ` Riku Voipio
2009-12-04 10:00   ` Arnaud Patard [this message]
2009-12-04 10:37     ` Paul Bolle

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=874oo76out.fsf@lechat.rtp-net.org \
    --to=arnaud.patard@rtp-net.org \
    --cc=pebolle@tiscali.nl \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /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.