The 05/07/2020 10:21, Richard Henderson wrote: > A reproducer would be most helpful. > > Something that can help is saving a VM snapshot with the kernel booted and the > user logged in, just ready to run the test program. Then you can get back to > exactly the state you want before things go wrong, even with a different qemu > build.
i got some time to create a reproducer (with public code), temporarily hosting the binaries at http://port70.net/~nsz/tmp/qemu-bug.tar.gz ~251M here echo ./bug.sh | ./qemu-bug.sh crashes in about 1 minute (where qemu-bug.sh loads a snapshot with root shell and ./bug.sh triggers the bug) the disk rootfs is based on https://distfiles.adelielinux.org/adelie/1.0/iso/rc1/adelie-rootfs-aarch64-1.0-rc1-20200206.txz the kernel Image is linux mte-v3 with reverting the commit "arm64: mte: Check the DT memory nodes for MTE support" qemu is static linked from the branch tgt-arm-mte. the userspace workload that triggers the bug is using the adelie linux package manager with a malloc with tagging. (the malloc implementation is a modified version of https://github.com/richfelker/mallocng-draft the code is on the disk image, it has known issues, but it should not crash qemu) i will remove the file after a few days. hope this helps.
