Receving on a socket with SO_TIMESTAMP fails with ENOBUFS on 32-bit musl

[asomers]

On 32-bit musl, for at least some versions of Linux and Musl, setting SO_TIMESTAMP on a socket will result in recvmsg succeeding, but the subsequent cmsgs() function failing with ENOBUFS. This is due to curious and poorly documented behavior within the Linux kernel. For at least some versions of Linux and musl, the exact versions not known, the kernel will actually return two separate cmsgs. The first is of type SCM_TIMESTAMP, and the second of type SCM_TIMESTAMP_NEW. An application could work like this, if it throws away any unknown or unexpected cmsgs. The problem for Nix users is the cmsg_space! call. If a Nix user does cmsg_space!(TimeVal) like they would on any other platform, then they will experience the ENOBUFS failure. Instead, a Nix user running on 32-bit musl must allow more buffer space. But I don't know exactly what invocation of cmsg_space! to use.
Another possibility is to set SO_TIMESTAMP_NEW on the socket instead of SO_TIMESTAMP. The Linux source code documentation suggests doing that might return only one SCM_TIMESTAMP message, of the new type. But I haven't tried it.
So in summary:

• The bug can be reproduced on a 64-bit Linux host by running a command like cargo test --all-features --doc --target i686-unknown-linux-musl sys::socket::ControlMessageOwned::ScmTimestamp
• A valid workaround for this bug is to add extra space to the cmsg_space! call.
• It would be helpful if a musl user could confirm the SO_TIMESTAMP_NEW theory.