On Mon, 19 Aug 2019 at 14:34, Aleksandar Markovic <aleksandar.m.m...@gmail.com> wrote: > I can't repro the problem either, but I do have a patch authored by an > engineer that left the company a while ago that seems to be at least related > to your scenario. May I ask you to test it (just apply it to QEMU ToT and > rerun the scenario to see if it changes the outcome) (feel free to experiment > and modify the changes)? I never managed to understand the purpose of that > patch (I lost the contact with the former engineer, and the patch is without > any comment), so I never dared to send it to the list, but I hope your > scenario may actually explain the purpose and the origin of the patch.
It's basically a more complete implementation of the suggestion from https://bugs.launchpad.net/qemu/+bug/1701798 comment #9 (it covers more syscalls and returns a valid guest errno rather than a host one). The intention, as you've guessed, is to paper over this guest-ld.so bug by preventing it from being able to open /etc/ld.so.cache at all (which will make it fall back to working without a cache). My feelings about it are the same as they were when I wrote comment #10 in reply: that patch would prevent us from picking up a legitimate ld.so.cache for the guest (in a chroot, for instance. I'm also not a fan of trying to work around specific guest code issues: I'd much rather this was just fixed in ld.so where it ought to be. You should be able to repro this bug on real hardware by copying an x86-64 ld.so.cache onto a big-endian machine :-) thanks -- PMM
