> On 1 Aug 2022, at 17:51, John Baldwin <[email protected]> wrote:
>
> 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
My impression is that the use cases can be largely the same as in (output)
MSG_TRUNC. One, for example, cares only about the packet header, thus they
submit a small buffer, but want to see the original length for accounting or
debugging purposes.
> 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().
I don’t have any objections on that, but don’t have any cycles to implement it
either - this is already third level of recursion from my original goal :-)
>
> Also, I think you missed the .Dd bump on recv.2.
Indeed! Thank you, should be fixed by 426afc8f5218.
>
> --
> John Baldwin
