Date: Wed, 28 Feb 2024 22:33:07 GMT From: Gleb Smirnoff <glebius@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: git: 152a6d410e47 - main - socket tests: remove MSG_TRUNC test for unix/seqpacket Message-ID: <202402282233.41SMX7jv010843@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by glebius: URL: https://cgit.FreeBSD.org/src/commit/?id=152a6d410e47a818fae905f6f4bd43f422146802 commit 152a6d410e47a818fae905f6f4bd43f422146802 Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2024-02-28 22:32:46 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-02-28 22:32:46 +0000 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 --- tests/sys/kern/socket_msg_trunc.c | 34 ---------------------------------- 1 file changed, 34 deletions(-) diff --git a/tests/sys/kern/socket_msg_trunc.c b/tests/sys/kern/socket_msg_trunc.c index b0ea724f0de0..bf1f0bf8ff42 100644 --- a/tests/sys/kern/socket_msg_trunc.c +++ b/tests/sys/kern/socket_msg_trunc.c @@ -153,39 +153,6 @@ ATF_TC_BODY(recv_trunc_afunix_dgram, tc) check_recvmsg(cs, ss, sa, sizes, nitems(sizes)); } -ATF_TC_WITHOUT_HEAD(recv_trunc_afunix_seqpacket); -ATF_TC_BODY(recv_trunc_afunix_seqpacket, tc) -{ - struct sockaddr_un sun; - struct sockaddr *sa; - int ss, nss, cs, rc; - - ss = socket(PF_UNIX, SOCK_SEQPACKET, 0); - ATF_REQUIRE(ss >= 0); - - bzero(&sun, sizeof(sun)); - sun.sun_family = AF_UNIX; - strlcpy(sun.sun_path, "test_check_recvmsg_socket", sizeof(sun.sun_path)); - sun.sun_len = sizeof(sun); - sa = (struct sockaddr *)&sun; - rc = bind(ss, sa, sa->sa_len); - ATF_REQUIRE_MSG(rc == 0, "bind failed: %s", strerror(errno)); - rc = listen(ss, 1); - ATF_REQUIRE_MSG(rc == 0, "listen failed: %s", strerror(errno)); - - cs = socket(PF_UNIX, SOCK_SEQPACKET, 0); - ATF_REQUIRE(cs >= 0); - rc = connect(cs, sa, sa->sa_len); - ATF_REQUIRE_MSG(rc == 0, "connect failed: %s", strerror(errno)); - nss = accept(ss, NULL, NULL); - ATF_REQUIRE(nss >= 0); - - size_t sizes[] = {80, 255, 256, 1024, 2000}; - check_recvmsg(cs, nss, sa, sizes, nitems(sizes)); - - ATF_REQUIRE(close(ss) == 0); -} - /* * Exercise the case where ktrace was used to dump a truncated buffer. */ @@ -245,7 +212,6 @@ ATF_TP_ADD_TCS(tp) ATF_TP_ADD_TC(tp, recv_trunc_afinet_udp); ATF_TP_ADD_TC(tp, recv_trunc_afinet6_udp); ATF_TP_ADD_TC(tp, recv_trunc_afunix_dgram); - ATF_TP_ADD_TC(tp, recv_trunc_afunix_seqpacket); ATF_TP_ADD_TC(tp, recvmsg_trunc_ktrace_uio); return (atf_no_error());
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202402282233.41SMX7jv010843>