On Wed, Jun 14, 2006 at 08:34:45PM -0400, Michael Gilbert wrote: > tag 297572 confimed > > hi bill, > > thanks for the info. looks like this problem does indeed exist. > > the question is: is it really a bug? the software seems to execute > just fine (although after a slight delay until the kernel spits back > ELOOP). is this normal/reasonable behavior, or should the devs go > through the effort to manually detect this situation? seems > unnecessary since its already handled.
It is a bug alright. There is simply no excuse for the actual behaviour. Depending on ELOOP to finish is not reasonnable because this is potentially exponential in the number of symlinks . Scanning all the files each time you start qemu-arm is a terrible performance loss. It seems my small test-case was too small and you did not venture to test the real test case. So here is a slightly larger test-case rm -r /tmp/arm mkdir /tmp/arm echo "#!/bin/sh\necho foo" > /tmp/arm/foo chmod a+x /tmp/arm/foo ln -s / /tmp/arm/lib qemu-arm -L /tmp/arm /tmp/arm/foo It is more than a slight delay here If you want to play you can also test this self-contained test-case: rm -r /tmp/arm mkdir /tmp/arm echo "#!/bin/sh\necho foo" > /tmp/arm/foo chmod a+x /tmp/arm/foo ln -s .. /tmp/arm/lib ln -s .. /tmp/arm/lib2 ln -s .. /tmp/arm/lib3 qemu-arm -L /tmp/arm /tmp/arm/foo The number of symlinks to scan before hitting ELOOP is about 3*10^9 If you are not interested to investigate the real isue, please at least do not try to pretend it does not exist. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
