mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Alexander Monakov <amonakov@ispras.ru>
Cc: musl@lists.openwall.com, Dominic Chen <d.c.ddcc@gmail.com>
Subject: Re: [musl] Issue with fread() and unaligned readv()
Date: Mon, 15 Mar 2021 18:29:16 -0400	[thread overview]
Message-ID: <20210315222916.GG32655@brightrain.aerifal.cx> (raw)
In-Reply-To: <alpine.LNX.2.20.13.2103160104210.17743@monopod.intra.ispras.ru>

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

  reply	other threads:[~2021-03-15 22:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 21:39 Dominic Chen
2021-03-15 21:51 ` Rich Felker
2021-03-15 22:09   ` Alexander Monakov
2021-03-15 22:29     ` Rich Felker [this message]
2021-03-15 22:42       ` Alexander Monakov
2021-03-16  2:13         ` Rich Felker
2021-03-16  9:30           ` Alexander Monakov
2021-03-16 23:54             ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210315222916.GG32655@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=amonakov@ispras.ru \
    --cc=d.c.ddcc@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).