summaryrefslogtreecommitdiff
path: root/src/signal/sh
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2019-12-17 20:12:03 -0500
committerRich Felker <dalias@aerifal.cx>2019-12-17 22:05:31 -0500
commitae388becb529428ac926da102f1d025b3c3968da (patch)
treed6c2c45d0c9e8a062cdab9eaba6bd9106cce2ded /src/signal/sh
parentf12bd8e05c8bb2c3e2b91d635887ec424ef8fbd9 (diff)
downloadmusl-ae388becb529428ac926da102f1d025b3c3968da.tar.gz
implement SO_TIMESTAMP[NS] fallback for kernels without time64 versions
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.
Diffstat (limited to 'src/signal/sh')
0 files changed, 0 insertions, 0 deletions