diff options
Diffstat (limited to 'results/classifier/deepseek-1/output/hypervisor/1877688')
| -rw-r--r-- | results/classifier/deepseek-1/output/hypervisor/1877688 | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/results/classifier/deepseek-1/output/hypervisor/1877688 b/results/classifier/deepseek-1/output/hypervisor/1877688 new file mode 100644 index 000000000..f04cc0521 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1877688 @@ -0,0 +1,40 @@ + +9p virtfs device reports error when opening certain files + +Reading certain files on a 9p mounted FS produces this error message: + +qemu-system-x86_64: VirtFS reply type 117 needs 12 bytes, buffer has 12, less than minimum + +After this error message is generated, further accesses to the 9p FS hangs whatever tries to access it. The Arch Linux guest system is otherwise usable. This happens with QEMU 5.0.0 and guest kernel version 5.6.11, hosted on an Arch Linux distro. I use the following command to launch QEMU: + +exec qemu-system-x86_64 -enable-kvm -display gtk -vga virtio -cpu host -m 4G -netdev tap,ifname=vmtap0,id=vn0,script=no,downscript=no -device virtio-net-pci,netdev=vn0 -kernel kernel.img -drive file=file.img,format=raw,if=virtio -virtfs local,path=mnt,mount_tag=host0,security_model=passthrough,id=host0 -append "console=ttyS0 root=/dev/vda rw" + +There's nothing relevant in the guest kernel logs as far as I'm aware of with loglevel set to 7. + +Here's a C program to trigger this behavior. I don't think it matters what the contents of "file" or its size is. + +Looks like being introduced by this change: +https://patchwork.kernel.org/patch/11319993/ + +More specifically this one exactly: + +- if (buf_size < size) { ++ if (buf_size < P9_IOHDRSZ) { + + + +The following patch should fix this bug for the kvm backend (not for the XEN backend yet). + +Please let me know if it fixes this bug for you. + +Thanks, it works. + +Fix is now committed on master as SHA-1 cf45183b718f02b1369e18c795dc51bc1821245d, which actually just reverted the mentioned commit that was leading to this broken behavior: +https://github.com/qemu/qemu/commit/cf45183b718f02b1369e18c795dc51bc1821245d + +The original Xen transport bug that motivated that change, was now fixed differently by handling that Xen issue solely on Xen transport driver side: +https://github.com/qemu/qemu/commit/a4c4d462729466c4756bac8a0a8d77eb63b21ef7 + + +Fixed in QEMU 5.1 release. + |