]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
socket tests: remove MSG_TRUNC test for unix/seqpacket
authorGleb Smirnoff <glebius@FreeBSD.org>
Wed, 28 Feb 2024 22:32:46 +0000 (14:32 -0800)
committerGleb Smirnoff <glebius@FreeBSD.org>
Wed, 28 Feb 2024 22:32:46 +0000 (14:32 -0800)
commit152a6d410e47a818fae905f6f4bd43f422146802
treefc0a93dc5401e35c71fd5f0903814ca845a88e9e
parent706d465dae6aa3e1b567299b9e80eb574b6c5abf
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