Re: git: be1f485d7d6b - main - sockets: add MSG_TRUNC flag handling for recvfrom()/recvmsg().

From: John Baldwin <jhb_at_FreeBSD.org>
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