Date: Tue, 16 Mar 2021 01:42:48 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com cc: Dominic Chen <d.c.ddcc@...il.com> Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.