[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.2103160137290.17743@monopod.intra.ispras.ru>
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.
