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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ