From owner-dev-commits-src-all@freebsd.org Mon Sep 13 20:43:19 2021 Return-Path: Delivered-To: dev-commits-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A7E3A6A9703; Mon, 13 Sep 2021 20:43:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7djM3pGlz3FZ1; Mon, 13 Sep 2021 20:43:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id D8F68ABD; Mon, 13 Sep 2021 20:43:18 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Michael Tuexen Cc: Mark Johnston , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" References: <202109122039.18CKdpwW094531@gitrepo.freebsd.org> <270ac6c6-1fdf-879a-cbea-ef43200ef12a@FreeBSD.org> From: John Baldwin Subject: Re: git: b864b67a0d19 - main - socket: Do not include control messages in FIONREAD return value Message-ID: <4ae85e22-a95f-5046-fe7d-40f2cc881c82@FreeBSD.org> Date: Mon, 13 Sep 2021 13:43:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: dev-commits-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 20:43:19 -0000 On 9/13/21 12:25 PM, Michael Tuexen wrote: >> On 13. Sep 2021, at 18:29, John Baldwin 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 >>> AuthorDate: 2021-09-12 20:05:49 +0000 >>> Commit: Mark Johnston >>> 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