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 4924 invoked from network); 15 Mar 2021 22:29:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Mar 2021 22:29:32 -0000 Received: (qmail 26346 invoked by uid 550); 15 Mar 2021 22:29:29 -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 26324 invoked from network); 15 Mar 2021 22:29:29 -0000 Date: Mon, 15 Mar 2021 18:29:16 -0400 From: Rich Felker To: Alexander Monakov Cc: musl@lists.openwall.com, Dominic Chen Message-ID: <20210315222916.GG32655@brightrain.aerifal.cx> References: <50e56e3e-d448-c568-b3d8-fbab98939ff8@gmail.com> <20210315215120.GF32655@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Issue with fread() and unaligned readv() On Tue, Mar 16, 2021 at 01:09:16AM +0300, Alexander Monakov wrote: > On Mon, 15 Mar 2021, Rich Felker wrote: > > > On Mon, Mar 15, 2021 at 05:39:43PM -0400, Dominic Chen wrote: > > > Not sure this counts as a problem in musl or the application, but > > > I've been debugging a return error of EINVAL from `fread(&buf, 8, > > > 16, f)`, where `f = fopen("/proc/self/pagemap", "r")`. Internally, > > > musl converts this into a call to `readv(f->fd, iov, 2)`, where `iov > > > = {{iov_base = buf, iov_len = 127}, {iov_base = f->buf, iov_len = > > > 1024}}`. However, it turns out that the kernel VFS read > > > implementation inside `pagemap_read` checks that both the file > > > position and count are divisible by PM_ENTRY_BYTES (8 on x86_64), > > > otherwise it rejects the read with EINVAL. In comparison, glibc's > > > `_IO_file_xsgetn` does appear to try to maintain read alignment, > > > although I haven't looked at it in detail. > > > > You can't use stdio to read or write special files/devices that depend > > on the reads or writes happening in particular units, because the > > relationship between stdio operations and the underlying > > buffer-fill/flush operations on the underlying fd is unspecified. It's > > really unfortunate that the kernel lies that procfs files are regular > > files but doesn't give them regular-file semantics, but you really > > need to use direct operations on the fd in the units the interface > > requires, rather than stdio, to work with these files. > > Where does iov_len = 127 for the first iov tuple come from, though? > >From fread arguments I'd expect 8 * 16 = 128. > > 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. This exact situation arises all the time with one very common type of file: tty devices. :( Rich