On 7/30/22 11:46 AM, Alexander V. Chernikov wrote:
The branch main has been updated by melifaro:
URL:
https://cgit.FreeBSD.org/src/commit/?id=be1f485d7d6bebc53b055cc165a11ada0ab5fb17
commit be1f485d7d6bebc53b055cc165a11ada0ab5fb17
Author: Alexander V. Chernikov <[email protected]>
AuthorDate: 2022-07-25 19:46:40 +0000
Commit: Alexander V. Chernikov <[email protected]>
CommitDate: 2022-07-30 18:21:51 +0000
sockets: add MSG_TRUNC flag handling for recvfrom()/recvmsg().
Implement Linux-variant of MSG_TRUNC input flag used in recv(), recvfrom() and recvmsg().
Posix defines MSG_TRUNC as an output flag, indicating packet/datagram
truncation.
Linux extended it a while (~15+ years) ago to act as input flag,
resulting in returning the full packet size regarless of the input
buffer size.
It's a (relatively) popular pattern to do recvmsg( MSG_PEEK | MSG_TRUNC)
to get the
packet size, allocate the buffer and issue another call to fetch the
packet.
In particular, it's popular in userland netlink code, which is the primary
driving factor of this change.
This commit implements the MSG_TRUNC support for SOCK_DGRAM sockets (udp, unix and all soreceive_generic() users).
In general I like this as I've long wanted a kind of FIONREAD but just
for the next messsage rather than whole socket buffer.
Two thoughts:
1) Why is it permissible (vs an EINVAL error) to pass MSG_TRUNC without
MSG_PEEK? If a developer wants to skip a message they can do a normal
read with a zero-sized buffer already which is more portable. It
seems to me that we should return an error here rather than
permitting it?
2) It might nice to have a similar option for MSG_CTRUNC so that one
could pass in MSG_PEEK | MSG_TRUNC | MSG_CTRUNC to get the sizes of
both the data and control back from recvmsg().
Also, I think you missed the .Dd bump on recv.2.
--
John Baldwin
