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 /include | |
parent | ae388becb529428ac926da102f1d025b3c3968da (diff) | |
download | musl-114178dc8df79a5b1690ee1c7d6d90c79c76b6b7.tar.gz 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 'include')
0 files changed, 0 insertions, 0 deletions