Alright, I'm trying to classify this bug report as either user-mode or system-mode. Let me go through the details step by step. The problem is about `sendmsg` failing in QEMU when sending messages without `iov` but with ancillary data. The user provided a test case and strace outputs comparing native and QEMU environments. In native, both sendmsg calls succeed, while in QEMU, the first call (with msg_iovlen=0) is missing. I know that in Linux, `sendmsg` can handle zero-length `iov` as long as there's control data. The issue arises specifically in QEMU, suggesting it's related to how QEMU handles these system calls. QEMU emulates a system environment for user-mode processes. If the bug occurs when using QEMU to run applications, it might be an issue with how QEMU translates or executes the `sendmsg` call. Since it's about handling the message structure correctly, especially ancillary data without `iov`, this points towards user-mode emulation. In contrast, system-mode issues involve lower-level aspects like hardware or device drivers. Here, the problem is more about correct handling of socket operations in a userspace context, not related to hardware or privileged operations beyond what a normal application would do. So, it's likely a user-mode issue because QEMU's user-mode emulation isn't correctly processing `sendmsg` calls with zero-length `iov` but valid control data. user