From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751083AbdANB6C (ORCPT <rfc822;w@1wt.eu>);
        Fri, 13 Jan 2017 20:58:02 -0500
Received: from zeniv.linux.org.uk ([195.92.253.2]:33316 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750954AbdANB6C (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 13 Jan 2017 20:58:02 -0500
Date: Sat, 14 Jan 2017 01:57:57 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Alan J. Wylie" <alan@wylie.me.uk>,
        Thorsten Leemhuis <regressions@leemhuis.info>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn
Message-ID: <20170114015757.GZ1555@ZenIV.linux.org.uk>
References: <20170113201121.GQ1555@ZenIV.linux.org.uk>
 <CA+55aFwVgk8QwZKeU2xUGxS0rjRUsSKRYVVA-p+vHnaS5ixoAA@mail.gmail.com>
 <20170113204731.GS1555@ZenIV.linux.org.uk>
 <20170113215504.GT1555@ZenIV.linux.org.uk>
 <20170113215919.GU1555@ZenIV.linux.org.uk>
 <20170113221308.GV1555@ZenIV.linux.org.uk>
 <20170113225058.GW1555@ZenIV.linux.org.uk>
 <CA+55aFx-Lc2KooGGt3ohHZUM6cUpcHWxs2a_YUdL=4bdRyxNfA@mail.gmail.com>
 <20170114012428.GX1555@ZenIV.linux.org.uk>
 <CA+55aFwxt=SGNwzvnzaXAhabW0wHgLK6bTP9-jov9mQdk1rzvg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFwxt=SGNwzvnzaXAhabW0wHgLK6bTP9-jov9mQdk1rzvg@mail.gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jan 13, 2017 at 05:46:34PM -0800, Linus Torvalds wrote:
> On Fri, Jan 13, 2017 at 5:24 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Why would advance by 0 change ->iov_offset here?
> 
> That's not my worry. Advancing by zero obviously doesn't change the position.
> 
> But the _truncation_ of the rest requires iov_offset to be zero in
> order to actually truncate everything.
> 
> So I was worrying about something updating it, and then wanting to
> truncate things on error.
> 
> But you bring up the kinds of cases I worried about:
> 
> > On error it does use iov_iter_advance(), pretty much as a way to
> > trigger pipe_truncate().  There we directly reset ->iov_offset to 0
> > and ->idx to its original value.
> 
> Ok, this was the part I worried about. And this
> 
> > However, theoretically it is possible that ->read_iter() instance does
> > successful copy_to_iter() and then decides to return an error.  This
> >         } else if (ret < 0) {
> >                 to.idx = idx;
> >                 to.iov_offset = 0;
> >                 iov_iter_advance(&to, 0); /* to free what was emitted */
> > in generic_file_splice_read() catches any such cases.
> 
> So I'm happy with that last patch then, and my worries are laid to rest.

OK.  Let's wait for Alan to confirm that the last variant works and
I'll send a pull request (with Cc: stable # v4.9).