From patchwork Fri Sep 8 01:04:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Al Viro X-Patchwork-Id: 9943033 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 3BC7B60363 for ; Fri, 8 Sep 2017 01:04:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1BD5727D29 for ; Fri, 8 Sep 2017 01:04:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1087627F91; Fri, 8 Sep 2017 01:04:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6A8F527D29 for ; Fri, 8 Sep 2017 01:04:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750944AbdIHBEq (ORCPT ); Thu, 7 Sep 2017 21:04:46 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:33948 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852AbdIHBEp (ORCPT ); Thu, 7 Sep 2017 21:04:45 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1dq7ir-0004vC-Oy; Fri, 08 Sep 2017 01:04:41 +0000 Date: Fri, 8 Sep 2017 02:04:41 +0100 From: Al Viro To: Dave Chinner Cc: Dave Jones , "Darrick J. Wong" , Linux Kernel , linux-xfs@vger.kernel.org Subject: Re: iov_iter_pipe warning. Message-ID: <20170908010441.GZ5426@ZenIV.linux.org.uk> References: <20170421175430.GT29622@ZenIV.linux.org.uk> <20170428152955.mafs3f22srmm34aw@codemonkey.org.uk> <20170428164313.GK29622@ZenIV.linux.org.uk> <20170428165024.ofyl2atpjwohekqa@codemonkey.org.uk> <20170428172024.GL29622@ZenIV.linux.org.uk> <20170807201818.kykqzexce6ap6aik@codemonkey.org.uk> <20170828203130.y6dq5fqovev6wmrv@codemonkey.org.uk> <20170829042542.GO4757@magnolia> <20170906200337.b5wj3gpfebliindw@codemonkey.org.uk> <20170906234617.GW17782@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170906234617.GW17782@dastard> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Sep 07, 2017 at 09:46:17AM +1000, Dave Chinner wrote: > On Wed, Sep 06, 2017 at 04:03:37PM -0400, Dave Jones wrote: > > On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote: > > > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote: > > > > I'm still trying to narrow down an exact reproducer, but it seems having > > > > trinity do a combination of sendfile & writev, with pipes and regular > > > > files as fd's is the best repro. > > > > > > > > Is this a real problem, or am I chasing ghosts ? That it doesn't happen > > > > on ext4 or btrfs is making me wonder... > > > > > > I haven't heard of any problems w/ directio xfs lately, but OTOH > > > I think it's the only filesystem that uses iomap_dio_rw, which would > > > explain why ext4/btrfs don't have this problem. > > > > Another warning, from likely the same root cause. > > > > WARNING: CPU: 3 PID: 572 at lib/iov_iter.c:962 iov_iter_pipe+0xe2/0xf0 > > WARN_ON(pipe->nrbufs == pipe->buffers); > > * @nrbufs: the number of non-empty pipe buffers in this pipe > * @buffers: total number of buffers (should be a power of 2) > > So that's warning that the pipe buffer is already full before we > try to read from the filesystem? > > That doesn't seem like an XFS problem - it indicates the pipe we are > filling in generic_file_splice_read() is not being emptied by > whatever we are splicing the file data to.... Or that XFS in some conditions shoves into pipe more than it reports, so not all of that gets emptied, filling the sucker up after sufficient amount of iterations... There's at least one suspicious place in iomap_dio_actor() - if (!(dio->flags & IOMAP_DIO_WRITE)) { iov_iter_zero(length, dio->submit.iter); dio->size += length; return length; } which assumes that iov_iter_zero() always succeeds. That's very much _not_ true - neither for iovec-backed, not for pipe-backed. Orangefs read_one_page() is fine (it calls that sucker for bvec-backed iov_iter it's just created), but iomap_dio_actor() is not. I'm not saying that it will suffice, but we definitely need this: --- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/iomap.c b/fs/iomap.c index 269b24a01f32..4a671263475f 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -843,7 +843,7 @@ iomap_dio_actor(struct inode *inode, loff_t pos, loff_t length, /*FALLTHRU*/ case IOMAP_UNWRITTEN: if (!(dio->flags & IOMAP_DIO_WRITE)) { - iov_iter_zero(length, dio->submit.iter); + length = iov_iter_zero(length, dio->submit.iter); dio->size += length; return length; }