diff options
author | Rich Felker <dalias@aerifal.cx> | 2019-12-17 23:00:24 -0500 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2019-12-17 23:00:24 -0500 |
commit | 114178dc8df79a5b1690ee1c7d6d90c79c76b6b7 (patch) | |
tree | 79252dafb1daa2d69d8727a8ed97fe80fd7f985c /src/misc | |
parent | ae388becb529428ac926da102f1d025b3c3968da (diff) | |
download | musl-114178dc8df79a5b1690ee1c7d6d90c79c76b6b7.tar.gz musl-114178dc8df79a5b1690ee1c7d6d90c79c76b6b7.tar.bz2 musl-114178dc8df79a5b1690ee1c7d6d90c79c76b6b7.tar.xz musl-114178dc8df79a5b1690ee1c7d6d90c79c76b6b7.zip |
hook recvmmsg up to SO_TIMESTAMP[NS] fallback for pre-time64 kernels
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.
Diffstat (limited to 'src/misc')
0 files changed, 0 insertions, 0 deletions