Re: [musl] Issue with fread() and unaligned readv()

[Alexander Monakov <amonakov@ispras.ru>]

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