diff options
Diffstat (limited to 'results/classifier/016/user-level')
| -rw-r--r-- | results/classifier/016/user-level/02364653 | 390 | ||||
| -rw-r--r-- | results/classifier/016/user-level/23448582 | 292 |
2 files changed, 0 insertions, 682 deletions
diff --git a/results/classifier/016/user-level/02364653 b/results/classifier/016/user-level/02364653 deleted file mode 100644 index 5f067fb9a..000000000 --- a/results/classifier/016/user-level/02364653 +++ /dev/null @@ -1,390 +0,0 @@ -user-level: 0.943 -TCG: 0.521 -operating system: 0.478 -x86: 0.352 -debug: 0.253 -semantic: 0.157 -files: 0.120 -PID: 0.076 -i386: 0.057 -register: 0.045 -virtual: 0.044 -vnc: 0.030 -boot: 0.025 -device: 0.015 -kernel: 0.012 -architecture: 0.012 -ppc: 0.011 -hypervisor: 0.010 -alpha: 0.009 -performance: 0.008 -risc-v: 0.007 -arm: 0.006 -peripherals: 0.005 -network: 0.005 -socket: 0.005 -VMM: 0.004 -assembly: 0.004 -permissions: 0.003 -graphic: 0.002 -mistranslation: 0.001 -KVM: 0.001 - -[Qemu-devel] [BUG] Inappropriate size of target_sigset_t - -Hello, Peter, Laurent, - -While working on another problem yesterday, I think I discovered a -long-standing bug in QEMU Linux user mode: our target_sigset_t structure is -eight times smaller as it should be! - -In this code segment from syscalls_def.h: - -#ifdef TARGET_MIPS -#define TARGET_NSIG 128 -#else -#define TARGET_NSIG 64 -#endif -#define TARGET_NSIG_BPW TARGET_ABI_BITS -#define TARGET_NSIG_WORDS (TARGET_NSIG / TARGET_NSIG_BPW) - -typedef struct { - abi_ulong sig[TARGET_NSIG_WORDS]; -} target_sigset_t; - -... TARGET_ABI_BITS should be replaced by eight times smaller constant (in -fact, semantically, we need TARGET_ABI_BYTES, but it is not defined) (what is -needed is actually "a byte per signal" in target_sigset_t, and we allow "a bit -per signal"). - -All this probably sounds to you like something impossible, since this code is -in QEMU "since forever", but I checked everything, and the bug seems real. I -wish you can prove me wrong. - -I just wanted to let you know about this, given the sensitive timing of current -softfreeze, and the fact that I won't be able to do more investigation on this -in coming weeks, since I am busy with other tasks, but perhaps you can analyze -and do something which you consider appropriate. - -Yours, -Aleksandar - -Le 03/07/2019 à 21:46, Aleksandar Markovic a écrit : -> -Hello, Peter, Laurent, -> -> -While working on another problem yesterday, I think I discovered a -> -long-standing bug in QEMU Linux user mode: our target_sigset_t structure is -> -eight times smaller as it should be! -> -> -In this code segment from syscalls_def.h: -> -> -#ifdef TARGET_MIPS -> -#define TARGET_NSIG 128 -> -#else -> -#define TARGET_NSIG 64 -> -#endif -> -#define TARGET_NSIG_BPW TARGET_ABI_BITS -> -#define TARGET_NSIG_WORDS (TARGET_NSIG / TARGET_NSIG_BPW) -> -> -typedef struct { -> -abi_ulong sig[TARGET_NSIG_WORDS]; -> -} target_sigset_t; -> -> -... TARGET_ABI_BITS should be replaced by eight times smaller constant (in -> -fact, semantically, we need TARGET_ABI_BYTES, but it is not defined) (what is -> -needed is actually "a byte per signal" in target_sigset_t, and we allow "a -> -bit per signal"). -TARGET_NSIG is divided by TARGET_ABI_BITS which gives you the number of -abi_ulong words we need in target_sigset_t. - -> -All this probably sounds to you like something impossible, since this code is -> -in QEMU "since forever", but I checked everything, and the bug seems real. I -> -wish you can prove me wrong. -> -> -I just wanted to let you know about this, given the sensitive timing of -> -current softfreeze, and the fact that I won't be able to do more -> -investigation on this in coming weeks, since I am busy with other tasks, but -> -perhaps you can analyze and do something which you consider appropriate. -If I compare with kernel, it looks good: - -In Linux: - - arch/mips/include/uapi/asm/signal.h - - #define _NSIG 128 - #define _NSIG_BPW (sizeof(unsigned long) * 8) - #define _NSIG_WORDS (_NSIG / _NSIG_BPW) - - typedef struct { - unsigned long sig[_NSIG_WORDS]; - } sigset_t; - -_NSIG_BPW is 8 * 8 = 64 on MIPS64 or 4 * 8 = 32 on MIPS - -In QEMU: - -TARGET_NSIG_BPW is TARGET_ABI_BITS which is TARGET_LONG_BITS which is -64 on MIPS64 and 32 on MIPS. - -I think there is no problem. - -Thanks, -Laurent - -From: Laurent Vivier <address@hidden> -> -If I compare with kernel, it looks good: -> -... -> -I think there is no problem. -Sure, thanks for such fast response - again, I am glad if you are right. -However, for some reason, glibc (and musl too) define sigset_t differently than -kernel. Please take a look. I am not sure if this is covered fine in our code. - -Yours, -Aleksandar - -> -Thanks, -> -Laurent - -On Wed, 3 Jul 2019 at 21:20, Aleksandar Markovic <address@hidden> wrote: -> -> -From: Laurent Vivier <address@hidden> -> -> If I compare with kernel, it looks good: -> -> ... -> -> I think there is no problem. -> -> -Sure, thanks for such fast response - again, I am glad if you are right. -> -However, for some reason, glibc (and musl too) define sigset_t differently -> -than kernel. Please take a look. I am not sure if this is covered fine in our -> -code. -Yeah, the libc definitions of sigset_t don't match the -kernel ones (this is for obscure historical reasons IIRC). -We're providing implementations of the target -syscall interface, so our target_sigset_t should be the -target kernel's version (and the target libc's version doesn't -matter to us). On the other hand we will be using the -host libc version, I think, so a little caution is required -and it's possible we have some bugs in our code. - -thanks --- PMM - -> -From: Peter Maydell <address@hidden> -> -> -On Wed, 3 Jul 2019 at 21:20, Aleksandar Markovic <address@hidden> wrote: -> -> -> -> From: Laurent Vivier <address@hidden> -> -> > If I compare with kernel, it looks good: -> -> > ... -> -> > I think there is no problem. -> -> -> -> Sure, thanks for such fast response - again, I am glad if you are right. -> -> However, for some reason, glibc (and musl too) define sigset_t differently -> -> than kernel. Please take a look. I am not sure if this is covered fine in -> -> our code. -> -> -Yeah, the libc definitions of sigset_t don't match the -> -kernel ones (this is for obscure historical reasons IIRC). -> -We're providing implementations of the target -> -syscall interface, so our target_sigset_t should be the -> -target kernel's version (and the target libc's version doesn't -> -matter to us). On the other hand we will be using the -> -host libc version, I think, so a little caution is required -> -and it's possible we have some bugs in our code. -OK, I gather than this is not something that requires our immediate attention -(for 4.1), but we can analyze it later on. - -Thanks for response!! - -Sincerely, -Aleksandar - -> -thanks -> --- PMM - -Le 03/07/2019 à 22:28, Peter Maydell a écrit : -> -On Wed, 3 Jul 2019 at 21:20, Aleksandar Markovic <address@hidden> wrote: -> -> -> -> From: Laurent Vivier <address@hidden> -> ->> If I compare with kernel, it looks good: -> ->> ... -> ->> I think there is no problem. -> -> -> -> Sure, thanks for such fast response - again, I am glad if you are right. -> -> However, for some reason, glibc (and musl too) define sigset_t differently -> -> than kernel. Please take a look. I am not sure if this is covered fine in -> -> our code. -> -> -Yeah, the libc definitions of sigset_t don't match the -> -kernel ones (this is for obscure historical reasons IIRC). -> -We're providing implementations of the target -> -syscall interface, so our target_sigset_t should be the -> -target kernel's version (and the target libc's version doesn't -> -matter to us). On the other hand we will be using the -> -host libc version, I think, so a little caution is required -> -and it's possible we have some bugs in our code. -It's why we need host_to_target_sigset_internal() and -target_to_host_sigset_internal() that translates bits and bytes between -guest kernel interface and host libc interface. - -void host_to_target_sigset_internal(target_sigset_t *d, - const sigset_t *s) -{ - int i; - target_sigemptyset(d); - for (i = 1; i <= TARGET_NSIG; i++) { - if (sigismember(s, i)) { - target_sigaddset(d, host_to_target_signal(i)); - } - } -} - -void target_to_host_sigset_internal(sigset_t *d, - const target_sigset_t *s) -{ - int i; - sigemptyset(d); - for (i = 1; i <= TARGET_NSIG; i++) { - if (target_sigismember(s, i)) { - sigaddset(d, target_to_host_signal(i)); - } - } -} - -Thanks, -Laurent - -Hi Aleksandar, - -On Wed, Jul 3, 2019 at 12:48 PM Aleksandar Markovic -<address@hidden> wrote: -> -#define TARGET_NSIG_BPW TARGET_ABI_BITS -> -#define TARGET_NSIG_WORDS (TARGET_NSIG / TARGET_NSIG_BPW) -> -> -typedef struct { -> -abi_ulong sig[TARGET_NSIG_WORDS]; -> -} target_sigset_t; -> -> -... TARGET_ABI_BITS should be replaced by eight times smaller constant (in -> -fact, -> -semantically, we need TARGET_ABI_BYTES, but it is not defined) (what is needed -> -is actually "a byte per signal" in target_sigset_t, and we allow "a bit per -> -signal"). -Why do we need a byte per target signal, if the functions in linux-user/signal.c -operate with bits? - --- -Thanks. --- Max - -> -Why do we need a byte per target signal, if the functions in -> -linux-user/signal.c -> -operate with bits? -Max, - -I did not base my findings on code analysis, but on dumping size/offsets of -elements of some structures, as they are emulated in QEMU, and in real systems. -So, I can't really answer your question. - -Yours, -Aleksandar - -> --- -> -Thanks. -> --- Max - diff --git a/results/classifier/016/user-level/23448582 b/results/classifier/016/user-level/23448582 deleted file mode 100644 index 32096f4fa..000000000 --- a/results/classifier/016/user-level/23448582 +++ /dev/null @@ -1,292 +0,0 @@ -user-level: 0.896 -debug: 0.851 -virtual: 0.759 -kernel: 0.639 -operating system: 0.498 -TCG: 0.132 -x86: 0.132 -device: 0.126 -PID: 0.104 -ppc: 0.071 -hypervisor: 0.058 -VMM: 0.057 -risc-v: 0.041 -files: 0.031 -register: 0.028 -performance: 0.025 -socket: 0.020 -i386: 0.016 -arm: 0.013 -assembly: 0.010 -vnc: 0.009 -architecture: 0.007 -peripherals: 0.006 -semantic: 0.005 -network: 0.005 -KVM: 0.004 -alpha: 0.003 -boot: 0.003 -graphic: 0.003 -permissions: 0.003 -mistranslation: 0.001 - -[BUG REPORT] cxl process in infinity loop - -Hi, all - -When I did the cxl memory hot-plug test on QEMU, I accidentally connected -two memdev to the same downstream port, the command like below: - -> --object memory-backend-ram,size=262144k,share=on,id=vmem0 \ -> --object memory-backend-ram,size=262144k,share=on,id=vmem1 \ -> --device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ -> --device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \ -> --device cxl-upstream,bus=root_port0,id=us0 \ -> --device cxl-downstream,port=0,bus=us0,id=swport00,chassis=0,slot=5 \ -> --device cxl-downstream,port=0,bus=us0,id=swport01,chassis=0,slot=7 \ -same downstream port but has different slot! - -> --device cxl-type3,bus=swport00,volatile-memdev=vmem0,id=cxl-vmem0 \ -> --device cxl-type3,bus=swport01,volatile-memdev=vmem1,id=cxl-vmem1 \ -> --M -> -cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=64G,cxl-fmw.0.interleave-granularity=4k -> -\ -There is no error occurred when vm start, but when I executed the âcxl listâ -command to view -the CXL objects info, the process can not end properly. - -Then I used strace to trace the process, I found that the process is in -infinity loop: -# strace cxl list -...... -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -write(3, "1\n\0", 3) = 3 -close(3) = 0 -access("/run/udev/queue", F_OK) = 0 - -[Environment]: -linux: V6.10-rc3 -QEMU: V9.0.0 -ndctl: v79 - -I know this is because of the wrong use of the QEMU command, but I think we -should -be aware of this error in one of the QEMU, OS or ndctl side at least. - -Thanks -Xingtao - -On Tue, 2 Jul 2024 00:30:06 +0000 -"Xingtao Yao (Fujitsu)" <yaoxt.fnst@fujitsu.com> wrote: - -> -Hi, all -> -> -When I did the cxl memory hot-plug test on QEMU, I accidentally connected -> -two memdev to the same downstream port, the command like below: -> -> -> -object memory-backend-ram,size=262144k,share=on,id=vmem0 \ -> -> -object memory-backend-ram,size=262144k,share=on,id=vmem1 \ -> -> -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ -> -> -device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \ -> -> -device cxl-upstream,bus=root_port0,id=us0 \ -> -> -device cxl-downstream,port=0,bus=us0,id=swport00,chassis=0,slot=5 \ -> -> -device cxl-downstream,port=0,bus=us0,id=swport01,chassis=0,slot=7 \ -> -same downstream port but has different slot! -> -> -> -device cxl-type3,bus=swport00,volatile-memdev=vmem0,id=cxl-vmem0 \ -> -> -device cxl-type3,bus=swport01,volatile-memdev=vmem1,id=cxl-vmem1 \ -> -> -M -> -> cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=64G,cxl-fmw.0.interleave-granularity=4k -> -> \ -> -> -There is no error occurred when vm start, but when I executed the âcxl listâ -> -command to view -> -the CXL objects info, the process can not end properly. -I'd be happy to look preventing this on QEMU side if you send one, -but in general there are are lots of ways to shoot yourself in the -foot with CXL and PCI device emulation in QEMU so I'm not going -to rush to solve this specific one. - -Likewise, some hardening in kernel / userspace probably makes sense but -this is a non compliant switch so priority of a fix is probably fairly low. - -Jonathan - -> -> -Then I used strace to trace the process, I found that the process is in -> -infinity loop: -> -# strace cxl list -> -...... -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 -> -openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 -> -write(3, "1\n\0", 3) = 3 -> -close(3) = 0 -> -access("/run/udev/queue", F_OK) = 0 -> -> -[Environment]: -> -linux: V6.10-rc3 -> -QEMU: V9.0.0 -> -ndctl: v79 -> -> -I know this is because of the wrong use of the QEMU command, but I think we -> -should -> -be aware of this error in one of the QEMU, OS or ndctl side at least. -> -> -Thanks -> -Xingtao - |