linux-user: Fix length handling in host_to_target_cmsg
commitc2aeb2586bd258ad76fcfe308f883075e73ff1d2
authorPeter Maydell <peter.maydell@linaro.org>
Tue, 26 May 2015 18:46:31 +0000 (26 19:46 +0100)
committerRiku Voipio <riku.voipio@linaro.org>
Tue, 16 Jun 2015 05:21:01 +0000 (16 08:21 +0300)
treec76e0c77bd610e06e99691f4a0fa510e294746ef
parent79cb1f1d698da5e1e183863aa3c8a91b2e750664
linux-user: Fix length handling in host_to_target_cmsg

The previous code for handling payload length when converting
cmsg structures from host to target had a number of problems:
 * we required the msg->msg_controllen to declare the buffer
   to have enough space for final trailing padding (we were
   checking against CMSG_SPACE), whereas the kernel does not
   require this, and common userspace code assumes this. (In
   particular, glibc's "try to talk to nscd" code that it will
   run on startup will receive a cmsg with a 4 byte payload and
   only allocate 4 bytes for it, which was causing us to do
   the wrong thing on architectures that need 8-alignment.)
 * we weren't correctly handling the fact that the SO_TIMESTAMP
   payload may be larger for the target than the host
 * we weren't marking the messages with MSG_CTRUNC when we did
   need to truncate a message that wasn't truncated by the host,
   but were instead logging a QEMU message; since truncation is
   always the result of a guest giving us an insufficiently
   sized buffer, we should report it to the guest as the kernel
   does and don't log anything

Rewrite the parts of the function that deal with length to
fix these issues, and add a comment in target_to_host_cmsg
to explain why the overflow logging it does is a QEMU bug,
not a guest issue.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
linux-user/syscall.c