always try the time64 syscall first since we can use its success to conclude that no conversion is needed (any setsockopt for the timestamp options would have succeeded without need for fallbacks). otherwise, we have to remember the original controllen for each msghdr, requiring O(vlen) space, so vlen must be bounded. linux clamps it to IOV_MAX for sendmmsg only (not recvmmsg), but doing the same for recvmmsg is not unreasonable, especially since the limitation will only apply to old kernels. we could optimize to avoid trying SYS_recvmmsg_time64 first if all msghdrs have controllen zero, or support unlimited vlen by looping and emulating the timeout logic, but I'm not inclined to do complex and error-prone optimizations on a function that has so many underlying problems it should really never be used.
the definitions of SO_TIMESTAMP* changed on 32-bit archs in commit 38143339646a4ccce8afe298c34467767c899f51 to the new versions that provide 64-bit versions of timeval/timespec structure in control message payload. socket options, being state attached to the socket rather than function calls, are not trivial to implement as fallbacks on ENOSYS, and support for them was initially omitted on the assumption that the ioctl-based polling alternatives (SIOCGSTAMP*) could be used instead by applications if setsockopt fails. unfortunately, it turns out that SO_TIMESTAMP is sufficiently old and widely supported that a number of applications assume it's available and treat errors as fatal. this patch introduces emulation of SO_TIMESTAMP[NS] on pre-time64 kernels by falling back to setting the "_OLD" (time32) versions of the options if the time64 ones are not recognized, and performing translation of the SCM_TIMESTAMP[NS] control messages in recvmsg. since recvmsg does not know whether its caller is legacy time32 code or time64, it performs translation for any SCM_TIMESTAMP[NS]_OLD control messages it sees, leaving the original time32 timestamp as-is (it can't be rewritten in-place anyway, and memmove would be mildly expensive) and appending the converted time64 control message at the end of the buffer. legacy time32 callers will see the converted one as a spurious control message of unknown type; time64 callers running on pre-time64 kernels will see the original one as a spurious control message of unknown type. a time64 caller running on a kernel with native time64 support will only see the time64 version of the control message. emulation of SO_TIMESTAMPING is not included at this time since (1) applications which use it seem to be prepared for the possibility that it's not present or working, and (2) it can also be used in sendmsg control messages, in a manner that looks complex to emulate completely, and costly even when running on a time64-supporting kernel. corresponding changes in recvmmsg are not made at this time; they will be done separately.
somewhat analogous to commit d0b547dfb5f7678cab6bc39dd736ed6454357ca4, but here the omission of the null timeout check was in the time64 syscall code path. this code is not yet used except on x32.
without this, the SO_RCVTIMEO and SO_SNDTIMEO socket options would stop working on pre-5.1 kernels after time_t is switched to 64-bit and their values are changed to the new time64 versions. new code is written such that it's statically unreachable on 64-bit archs, and on existing 32-bit archs until the macro values are changed to activate 64-bit time_t.
the time64 syscall is used only if the timeout does not fit in 32 bits. after preprocessing, the code is unchanged on 64-bit archs. for 32-bit archs, the timeout now goes through an intermediate copy, meaning that the caller does not get back the updated timeout. this is based on my reading of the documentation, which does not document the updating as a contract you can rely on, and mentions that the whole recvmmsg timeout mechanism is buggy and unlikely to be useful. if it turns out that there's interest in making the remaining time officially available to callers, such functionality could be added back later.
The original logic considered each byte until it either found a 0 value or a value >= 192. This means if a string segment contained any byte >= 192 it was interepretted as a compressed segment marker even if it wasn't in a position where it should be interpretted as such. The fix is to adjust dn_skipname to increment by each segments size rather than look at each character. This avoids misinterpretting string segment characters by not considering those bytes.
addressing &out[k].sa was arguably undefined, despite &out[k] being defined the slot one past the end of an array, since the member access .sa is intervening between the [] operator and the & operator.
the backindex stored by getaddrinfo to allow freeaddrinfo to perform partial-free wrongly used the address result index, rather than the output slot index, and thus was only valid when they were equal (nservs==1). patch based on report with proposed fix by Markus Wichmann.
the specification for freeaddrinfo allows it to be used to free "arbitrary sublists" of the list returned by getaddrinfo. it's not clearly stated how such sublists come into existence, but the interpretation seems to be that the application can edit the ai_next pointers to cut off a portion of the list and then free it. actual freeing of individual list slots is contrary to the design of our getaddrinfo implementation, which has no failure paths after making a single allocation, so that light callers can avoid linking realloc/free. freeing individual slots is also incompatible with sharing the string for ai_canonname, which the current implementation does despite no requirement that it be present except on the first result. so, rather than actually freeing individual slots, provide a way to find the start of the allocated array, and reference-count it, freeing the memory all at once after the last slot has been freed. since the language in the spec is "arbitrary sublists", no provision for handling other constructs like multiple lists glued together, circular links, etc. is made. presumably passing such a construct to freeaddrinfo produces undefined behavior.
despite not being documented to do so in the standard or Linux documentation, attempts to udp connect to 127.0.0.1 or ::1 generate EADDRNOTAVAIL when the loopback device is not configured and there is no default route for IPv6. this caused getaddrinfo with AI_ADDRCONFIG to fail with EAI_SYSTEM and EADDRNOTAVAIL on some no-IPv6 configurations, rather than the intended behavior of detecting IPv6 as unsuppported and producing IPv4-only results. previously, only EAFNOSUPPORT was treated as unavailability of the address family being probed. instead, treat all errors related to inability to get an address or route as conclusive that the family being probed is unsupported, and only fail with EAI_SYSTEM on other errors. further improvements may be desirable, such as reporting EAI_AGAIN instead of EAI_SYSTEM for errors which are expected to be transient, but this patch should suffice to fix the serious regression.