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 2223 invoked from network); 15 Mar 2021 22:09:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Mar 2021 22:09:29 -0000 Received: (qmail 13555 invoked by uid 550); 15 Mar 2021 22:09:28 -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 13537 invoked from network); 15 Mar 2021 22:09:27 -0000 Date: Tue, 16 Mar 2021 01:09:16 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com cc: Dominic Chen In-Reply-To: <20210315215120.GF32655@brightrain.aerifal.cx> Message-ID: References: <50e56e3e-d448-c568-b3d8-fbab98939ff8@gmail.com> <20210315215120.GF32655@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: > 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). Alexander