linux-kernel - Re: 4.9.0 regression in pipe-backed iov

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwrsardsZpTn6MopNTPZnRUazyP5oRgU_3JLbLoWDYkpQ@mail.gmail.com>
Date:   Thu, 12 Jan 2017 15:02:13 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     "Alan J. Wylie" <alan@...ie.me.uk>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Thu, Jan 12, 2017 at 2:46 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> PS: what about the /proc/mounts contents?  If it's something 9p-backed kvm,
> your bisect might have been caught on the bug I'd mentioned - if the breakage
> you are seeing in 4.9.3 has started after that commit and before the
> backport of the fix, your bisect could converge there.  Does the
> reproducer trigger on 523ac9afc73a + cherry-pick of 8e54cadab447?

Looking at the strace that Alan just posted, I really think it's the
splice change that Alan bisected to.

In particular, this line:

    splice(5, NULL, 1, NULL, 9223372036854775807, 0) = -1 EAGAIN
(Resource temporarily unavailable)

and note that the commit in question introduces that -EAGAIN error code.

The old code never returned EAGAIN at all (well, it could do so later,
if NONBLOCK was set, obviously, but that doesn't seem to be the case
here).

So that commit seems to have introduced a new error case, and I
suspect systemd-nospawn simply doesn't handle it. It is expecting
splice_to_pipe() to actually block.

Ergo: I think we need to do a wait_for_space() somewhere, getting rid
of the EAGAIN.

Looking at the callers of "do_splice_to()", we already have the
wait_for_space() in do_splice(), but we do *not* have it in the
do_splice_from() case when both the input and output file descriptors
are pipes.

Hmm?

             Linus