git: b864b67a0d19 - main - socket: Do not include control messages in FIONREAD return value

[John Baldwin]

On 9/13/21 12:25 PM, Michael Tuexen wrote:
>> On 13. Sep 2021, at 18:29, John Baldwin <jhb at freebsd.org> wrote:
>>
>> On 9/12/21 1:39 PM, Mark Johnston wrote:
>>> The branch main has been updated by markj:
>>> URL: https://cgit.FreeBSD.org/src/commit/?id=b864b67a0d197f59ecf6698940600956ceee2cae
>>> commit b864b67a0d197f59ecf6698940600956ceee2cae
>>> Author:     Mark Johnston <markj at FreeBSD.org>
>>> AuthorDate: 2021-09-12 20:05:49 +0000
>>> Commit:     Mark Johnston <markj at FreeBSD.org>
>>> CommitDate: 2021-09-12 20:39:44 +0000
>>>      socket: Do not include control messages in FIONREAD return value
>>>           Some system software expects to be able to read at least the number of
>>>      bytes returned by FIONREAD.  When control messages are counted in this
>>>      return value, this assumption is violated.  Follow Linux and OpenBSD
>>>      here (as well as our own kevent(EVFILT_READ)) and only return the number
>>>      of data bytes available.
>>>           Reported by:    avg
>>>      MFC after:      2 weeks
>>
>> In a somewhat similar vein, it would be nice to eventually have new ioctls
>> to know how much data and control are available in the next message for
>> datagram-oriented sockets.  Right now if you are working with a datagram
>> socket with variable-sized messages there's no good way to know how big the
>> next message is (to resize a read buffer) as FIONREAD can count multiple
>> messages.  There's also no way at all to cope with control messages aside
>> from retrying with some naive algorithm like doubling the size if MSG_CTRUNC
>> is set, but that also requires always using MSG_PEEK so that you always
>> end up reading a message at least twice.
> That still requires two system calls. In SCTP, there is a CMSG you can
> receive with a messages, which contains the metadata of the next message
> you will receive.
> So it might be an idea to define a CMSG containing the length of the next
> message (if available).

We could at least just have a single ioctl that returns a struct with
two members (data length and control length) perhaps to get it back down
to just 1 syscall similar to FIONREAD.

-- 
John Baldwin