From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6616 invoked from network); 15 Mar 2021 22:43:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Mar 2021 22:43:03 -0000 Received: (qmail 1208 invoked by uid 550); 15 Mar 2021 22:42:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1190 invoked from network); 15 Mar 2021 22:42:59 -0000 Date: Tue, 16 Mar 2021 01:42:48 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com cc: Dominic Chen In-Reply-To: <20210315222916.GG32655@brightrain.aerifal.cx> Message-ID: References: <50e56e3e-d448-c568-b3d8-fbab98939ff8@gmail.com> <20210315215120.GF32655@brightrain.aerifal.cx> <20210315222916.GG32655@brightrain.aerifal.cx> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [musl] Issue with fread() and unaligned readv() On Mon, 15 Mar 2021, Rich Felker wrote: > > If musl always does such off-by-one, it is an efficiency issue (forces > > a copy with mismatching source/dest alignment). > > It's necessary to work around a kernel bug, whereby the kernel fails > to honor the requirement that a readv of total length n behave > identically, except for where the data is stored, as a single read of > length n. For vfs backends that don't implement a proper readv > operation, the kernel executes readv as a sequence of reads. When this > happens, if the amount of data to read is exactly the length of the > first iov (the length requested by the application), continuing to the > second iov with no more data available will cause the operation to > block indefinitely until more data is available. By reducing the > length of the first iov (the caller's buffer) by 1, we ensure that at > least 1 byte of the second iov (the FILE's buffer) is actually needed > to satisfy the caller, and thus that the call will return without > blocking as soon as everything the caller requested is available. Thanks. Can musl reduce the first iov tuple by, say, 8 bytes rather than 1 byte, to avoid forcing the kernel to perform a misaligned copy? Alexander