Date: Mon, 1 Aug 2022 09:51:43 -0700 From: John Baldwin <jhb@FreeBSD.org> To: "Alexander V. Chernikov" <melifaro@FreeBSD.org>, src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: be1f485d7d6b - main - sockets: add MSG_TRUNC flag handling for recvfrom()/recvmsg(). Message-ID: <0aec0f80-0bb2-7bf7-a87b-e97e18674a19@FreeBSD.org> In-Reply-To: <202207301846.26UIko7G080500@gitrepo.freebsd.org> References: <202207301846.26UIko7G080500@gitrepo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0aec0f80-0bb2-7bf7-a87b-e97e18674a19>