qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH][UPDATED] Fix path mangling in linux-user/path.c


From: Lauri Leukkunen
Subject: Re: [Qemu-devel] [PATCH][UPDATED] Fix path mangling in linux-user/path.c
Date: Mon, 18 Jun 2007 09:02:17 +0300
User-agent: Mutt/1.5.13 (2006-08-11)

On 17/06/07 17:30 +0100, Thiemo Seufer wrote:
> Lauri Leukkunen wrote:
> > Attached patch fixes the linux-user path mangling code for use with
> > real target root filesystems that have nasty symlinks and lots of
> > files. The old code is terribly slow and can easily end up going
> > through the entire host system /usr hierarchy in a recursive loop.
> > 
> > Compared to the previous version of this patch, fixes an issue with
> > attempting to free() a pointer returned by GNU basename().
> 
> I gave it a try, and found:
>   - It loses the path caching (which should be done incrementally to
>     avoid the slowness you observe)

Current path mangling is not just slow, it gets stuck in a loop for 
15 minutes on my box and eats all my RAM until it exhausts all virtual memory:

3976 lleukkun  18   0 2641m 1.5g  188 R   68 77.4   1:26.36 qemu-arm

So I don't know if losing a bit of caching is that bad in comparison.
I've implemented a kinda similar path mangling system for scratchbox2, there
I'm caching the translations in a cache dir as symlinks, cuts down the
mangling overhead quite a bit, but on the other hand sb2 needs to do a lot
more work to determine how to mangle the path. Not sure it's worth the
trouble for qemu.

It seems on a current debian/testing it no longer works at all, it used to
hog all memory and then (maybe after getting a NULL from malloc()?)
continued, now it just eats all swap and keeps going as long as the kernel
permits. If you want to see the effect get a maemo rootfs from here:
http://repository.maemo.org/stable/3.1/armel/maemo-sdk-rootstrap_3.1_armel.tgz
and try giving the extracted dir to qemu-arm -L /path/to/the/rootfs

It gets tripped up by the /usr/X11R6/bin/X11 -> . symlink, don't ask me why
such a link is needed ;)

>   - It misses to do error handling on malloc() returns
>   - It is broken, an emulated "/bin/ls /.." shows it ascends above
>     the root.

I'll try to provide an updated patch with these addressed tomorrow.

/lauri




reply via email to

[Prev in Thread] Current Thread [Next in Thread]