#
152a6d41 |
|
28-Feb-2024 |
Gleb Smirnoff <glebius@FreeBSD.org> |
socket tests: remove MSG_TRUNC test for unix/seqpacket The PF_UNIX/SOCK_SEQPACKET was marked as PR_ATOMIC and that made soreceive_generic() to treat it pretty much as a datagram socket. However, POSIX says: The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type, and is also connection-oriented. The only difference between these types is that record boundaries are maintained using the SOCK_SEQPACKET type. A record can be sent using one or more output operations and received using one or more input operations, but a single operation never transfers parts of more than one record. Record boundaries are visible to the receiver via the MSG_EOR flag in the received message flags returned by the recvmsg() function. It is protocol-specific whether a maximum record size is imposed. What the test was doing is checking if MSG_TRUNC would report the space required to return up the end of next mbuf record in the socket buffer. Apparently the test assumed that this boundary is defined by the write(2) size on the peer socket. This was true in test conditions, but I'm not sure it would always be true - sbcompress() may merge mbufs. Anyway, the mbuf boundaries are internal socket buffer implementation, they are not SOCK_SEQPACKET records. The records need to be explicitly marked with MSG_EOR by sender, and the test definitely wasn't doing that. Reviewed by: tuexen, markj Differential Revision: https://reviews.freebsd.org/D43707
|
#
8e2c2992 |
|
09-Jan-2024 |
Brooks Davis <brooks@FreeBSD.org> |
socket_msg_trunc: allocate a large enough buffer Allocate 9000 bytes to match the largest requsted size. Add a check to prevent the list of sizes and buffer size from getting out of sync again. Reviewed by: markj Found with: CheriBSD Differential Revision: https://reviews.freebsd.org/D43340
|
#
4bd1e196 |
|
17-Oct-2023 |
Mark Johnston <markj@FreeBSD.org> |
socket tests: Build fix Fixes: d8735eb7acc0 ("socket tests: Add a regression test for ktrace+recv(MSG_TRUNC)") Reported by: Jenkins
|
#
d8735eb7 |
|
16-Oct-2023 |
Mark Johnston <markj@FreeBSD.org> |
socket tests: Add a regression test for ktrace+recv(MSG_TRUNC) MFC after: 1 week
|
#
b5e7dbac |
|
16-Oct-2023 |
Mark Johnston <markj@FreeBSD.org> |
socket tests: Clean up the MSG_TRUNC regression tests a bit - Fix style. - Move test case-specific code out of the shared function and into the individual test cases. - Remove unneeded setting of SO_REUSEPORT. - Avoid unnecessary copying. - Use ATF_REQUIRE* instead of ATF_CHECK*. The former cause test execution to stop after a failed assertion, which is what we want. - Add a test case for AF_LOCAL/SOCK_SEQPACKET sockets. MFC after: 1 week
|
#
1d386b48 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
be1f485d |
|
25-Jul-2022 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
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). PR: kern/176322 Reviewed by: pauamma(doc) Differential Revision: https://reviews.freebsd.org/D35909 MFC after: 1 month
|