diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/829 | 29 | ||||
| -rw-r--r-- | results/classifier/108/other/829455 | 58 |
2 files changed, 87 insertions, 0 deletions
diff --git a/results/classifier/108/other/829 b/results/classifier/108/other/829 new file mode 100644 index 00000000..1337a020 --- /dev/null +++ b/results/classifier/108/other/829 @@ -0,0 +1,29 @@ +graphic: 0.848 +performance: 0.841 +device: 0.788 +other: 0.585 +boot: 0.572 +permissions: 0.561 +files: 0.554 +semantic: 0.545 +network: 0.477 +PID: 0.476 +debug: 0.452 +vnc: 0.424 +socket: 0.411 +KVM: 0.215 + +user space emulation: openat() seems to defeat sysroot path translation +Description of problem: +It appears that the user space emulation code is doing some path manipulation of some syscalls to sometimes prefix them with the sysroot. This seems to be interacting badly sometimes with certain usage patterns. This was noticed because a test suite of various libc calls was failing under `qemu-arm`, and a `strace` of the qemu-arm process revealed that the translated paths were being inconsistently applied. + +In particular, the sequence which fails is: +* create a file in `/tmp/`. +* open `/tmp` itself. This succeeds, but `strace` reveals that it actually opened `SYSROOT/tmp/`. +* `openat(tmpfd, tmpfile_name)` then fails, as the fd provided to openat is actually inside the sysroot, not at `/tmp` as expected. +Steps to reproduce: +1. Get toolchain https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2 +2. Compile attached test program [test_openat.c](/uploads/69eb997256ff29d2178be85531c6b3c6/test_openat.c) +3. Try to run under `qemu-arm`. + +This code passes in non-emulated situations, but fails under user-space emulation. Presumably it would also pass under full system emulation. diff --git a/results/classifier/108/other/829455 b/results/classifier/108/other/829455 new file mode 100644 index 00000000..925a03ac --- /dev/null +++ b/results/classifier/108/other/829455 @@ -0,0 +1,58 @@ +network: 0.843 +socket: 0.696 +KVM: 0.677 +other: 0.587 +device: 0.566 +PID: 0.489 +vnc: 0.432 +semantic: 0.422 +debug: 0.389 +performance: 0.361 +permissions: 0.330 +boot: 0.292 +graphic: 0.242 +files: 0.232 + +user mode network stack - hostfwd not working with restrict=y + +I find that explicit hostfwd commands do not seem to work with restrict=yes option, even if the docs clearly state that hostfwd should override restrict setting. + +I am using this config: + +-net user,name=test,net=192.168.100.0/24,host=192.168.100.44,restrict=y,hostfwd=tcp:127.0.0.1:3389-192.168.100.1:3389 + +(my guest has static IP address configured as 192.168.100.1/24) + +and I cannot log into my guest via rdp. the client hanging indefinitely. +by just changing to "restrict=no" I can log in. + +maybe I am doing something wrong, but I cannot figure out what. + +running QEMU emulator version 0.14.0 (qemu-kvm-0.14.0) + +Did you guys merge back the fix in: + +http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01519.html +? + +On Fri, Jun 14, 2013 at 10:59:10AM -0000, Axel Hübl wrote: +> Did you guys merge back the fix in: +> +> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01519.html +> ? + +This patch has not been applied. CCing Jan Kiszka, slirp maintainer. + +Stefan + + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=b5a87d26e848945eb8 + +It seems that's problem persist with this patch ( qemu 2.7rc2) +Regards + +Sorry for this spam, +it's just a routing problem . +Regards + |