Re: git: be1f485d7d6b - main - sockets: add MSG_TRUNC flag handling for recvfrom()/recvmsg().
- Reply: Alexander V. Chernikov: "Re: git: be1f485d7d6b - main - sockets: add MSG_TRUNC flag handling for recvfrom()/recvmsg()."
- In reply to: Alexander V. Chernikov: "git: be1f485d7d6b - main - sockets: add MSG_TRUNC flag handling for recvfrom()/recvmsg()."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 01 Aug 2022 16:51:43 UTC
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 <melifaro@FreeBSD.org>
> AuthorDate: 2022-07-25 19:46:40 +0000
> Commit: Alexander V. Chernikov <melifaro@FreeBSD.org>
> 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