Date: Tue, 2 Aug 2022 14:32:58 +0100 From: "Alexander V. Chernikov" <melifaro@ipfw.ru> To: John Baldwin <jhb@FreeBSD.org> Cc: "Alexander V. Chernikov" <melifaro@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org> Subject: Re: git: be1f485d7d6b - main - sockets: add MSG_TRUNC flag handling for recvfrom()/recvmsg(). Message-ID: <48AE1817-F3C5-4DBD-94DA-CAFC699B2C4D@ipfw.ru> In-Reply-To: <0aec0f80-0bb2-7bf7-a87b-e97e18674a19@FreeBSD.org> References: <202207301846.26UIko7G080500@gitrepo.freebsd.org> <0aec0f80-0bb2-7bf7-a87b-e97e18674a19@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 1 Aug 2022, at 17:51, John Baldwin <jhb@FreeBSD.org> wrote: >=20 > 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=3Dbe1f485d7d6bebc53b055cc165a11ada= 0ab5fb17 >> 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). >=20 > 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. >=20 > Two thoughts: >=20 > 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? >=20 > 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=E2=80=99t have any objections on that, but don=E2=80=99t have any = cycles to implement it either - this is already third level of recursion = from my original goal :-) >=20 > Also, I think you missed the .Dd bump on recv.2. Indeed! Thank you, should be fixed by 426afc8f5218. >=20 > --=20 > John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AE1817-F3C5-4DBD-94DA-CAFC699B2C4D>