Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp161721ybl; Wed, 11 Dec 2019 15:51:29 -0800 (PST) X-Google-Smtp-Source: APXvYqzIVTF2VLPYffHSCM5qdhxzlO+rs3Yt7V7SlFoKCk5oI3/ZSYxF15e16ge2FumG8+8Qsc9W X-Received: by 2002:a9d:da2:: with SMTP id 31mr4472481ots.319.1576108289398; Wed, 11 Dec 2019 15:51:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576108289; cv=none; d=google.com; s=arc-20160816; b=VsJteZYB54wQ0/9p5AgZzG2/Hv+9XTs1vI8ZFhfZGtpsSzwthzRmT2LYHgna8X3NIN bPCiuS5j0usVu217sdfZaP9cq2IWoAX/ebF/7KNvRHK9rafBnN3tgZjqYGQT2CCY0IS6 WpPCNN2kHiB5DPMVRaXiqpPux14u9/dSCc57kMM/EVDKmvEHBGn3fEeN3n+/K1rax0yu rTiykfmCHjDxPZyKLG9T60Ww0CMIrhF8yVow4/WklcFMTpO3jNYTPAaSEe6qpzX8qROV fl52Idm7k/yF6hA3tigLII6s9NxOUJhqZxt6g/1LUGY3KEQ+wt2tpC4dVlgFdUM+dIE5 TRkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=35OmFWo48p2I8sCWu+lcr8Up+ml7zvzOFo/OoLNTLhg=; b=hdrIXeRz63RESdpu0s57i9OfAoD1DhXXqccK3CfDJRdETK1hGZZ5SKJ22Xxh2EB5Eu A5jBkYvP7ArHWbqH8AwaDTlUSLo6aAjZ4kPkCJSjh/vBZRs72c2GVmPsa/2v1fHznr94 YSWwh+cZdoTF6RhM6mf4QWlc14NuaOkyld1qG79Pk8CMZzHWwC/p6p5iC475SCCwThCx fAH0t5QcljXYV1QBQKDryd1AvC7yeYKsGW38DW3gs3IgYzG1XXx8zK3h6KYvS20VJvu8 W3bbEdTSQN5FEs2SX0gaoqY7Jn1MPsBhoxdREHKRrEg2JBLALs05pYGQy7tkAglGvSJK tNXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=toshiba.co.jp Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x20si2085095otq.222.2019.12.11.15.51.17; Wed, 11 Dec 2019 15:51:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=toshiba.co.jp Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727132AbfLKXuo (ORCPT + 99 others); Wed, 11 Dec 2019 18:50:44 -0500 Received: from mo-csw1514.securemx.jp ([210.130.202.153]:40476 "EHLO mo-csw.securemx.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726890AbfLKXuo (ORCPT ); Wed, 11 Dec 2019 18:50:44 -0500 Received: by mo-csw.securemx.jp (mx-mo-csw1514) id xBBNoRkW006249; Thu, 12 Dec 2019 08:50:28 +0900 X-Iguazu-Qid: 34tMQJyII3CBYi1sWp X-Iguazu-QSIG: v=2; s=0; t=1576108227; q=34tMQJyII3CBYi1sWp; m=4p+g4j2xam2YUSHpoqyygsho0cdntaFG34MarWhkTHM= Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) by relay.securemx.jp (mx-mr1511) id xBBNoQKg013514; Thu, 12 Dec 2019 08:50:26 +0900 Received: from enc01.localdomain ([106.186.93.100]) by imx2.toshiba.co.jp with ESMTP id xBBNoQuh010066; Thu, 12 Dec 2019 08:50:26 +0900 (JST) Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.localdomain with ESMTP id xBBNoQcE005547; Thu, 12 Dec 2019 08:50:26 +0900 Date: Thu, 12 Dec 2019 08:50:25 +0900 From: Nobuhiro Iwamatsu To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Dave Chinner , "Darrick J. Wong" , Christoph Hellwig , Sasha Levin Subject: Re: [PATCH 4.19 077/243] iomap: dio data corruption and spurious errors when pipes fill X-TSB-HOP: ON Message-ID: <20191211235025.xukuecbyuub6hakt@toshiba.co.jp> References: <20191211150339.185439726@linuxfoundation.org> <20191211150344.304750036@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191211150344.304750036@linuxfoundation.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 11, 2019 at 04:03:59PM +0100, Greg Kroah-Hartman wrote: > From: Dave Chinner > > [ Upstream commit 4721a6010990971440b4ffefbdf014976b8eda2f ] > > When doing direct IO to a pipe for do_splice_direct(), then pipe is > trivial to fill up and overflow as it can only hold 16 pages. At > this point bio_iov_iter_get_pages() then returns -EFAULT, and we > abort the IO submission process. Unfortunately, iomap_dio_rw() > propagates the error back up the stack. > > The error is converted from the EFAULT to EAGAIN in > generic_file_splice_read() to tell the splice layers that the pipe > is full. do_splice_direct() completely fails to handle EAGAIN errors > (it aborts on error) and returns EAGAIN to the caller. > > copy_file_write() then completely fails to handle EAGAIN as well, > and so returns EAGAIN to userspace, having failed to copy the data > it was asked to. > > Avoid this whole steaming pile of fail by having iomap_dio_rw() > silently swallow EFAULT errors and so do short reads. > > To make matters worse, iomap_dio_actor() has a stale data exposure > bug bio_iov_iter_get_pages() fails - it does not zero the tail block > that it may have been left uncovered by partial IO. Fix the error > handling case to drop to the sub-block zeroing rather than > immmediately returning the -EFAULT error. > > Signed-off-by: Dave Chinner > Reviewed-by: Darrick J. Wong > Reviewed-by: Christoph Hellwig > Signed-off-by: Darrick J. Wong > Signed-off-by: Sasha Levin This commit also seems to require the following 2 commits: commit 8f67b5adc030553fbc877124306f3f3bdab89aa8 Author: Darrick J. Wong Date: Sun Dec 2 08:38:07 2018 -0800 iomap: partially revert 4721a601099 (simulated directio short read on EFAULT) In commit 4721a601099, we tried to fix a problem wherein directio reads into a splice pipe will bounce EFAULT/EAGAIN all the way out to userspace by simulating a zero-byte short read. This happens because some directio read implementations (xfs) will call bio_iov_iter_get_pages to grab pipe buffer pages and issue asynchronous reads, but as soon as we run out of pipe buffers that _get_pages call returns EFAULT, which the splice code translates to EAGAIN and bounces out to userspace. In that commit, the iomap code catches the EFAULT and simulates a zero-byte read, but that causes assertion errors on regular splice reads because xfs doesn't allow short directio reads. This causes infinite splice() loops and assertion failures on generic/095 on overlayfs because xfs only permit total success or total failure of a directio operation. The underlying issue in the pipe splice code has now been fixed by changing the pipe splice loop to avoid avoid reading more data than there is space in the pipe. Therefore, it's no longer necessary to simulate the short directio, so remove the hack from iomap. Fixes: 4721a601099 ("iomap: dio data corruption and spurious errors when pipes fill") Reported-by: Murphy Zhou Ranted-by: Amir Goldstein Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong i commit 17614445576b6af24e9cf36607c6448164719c96 Author: Darrick J. Wong Date: Fri Nov 30 10:37:49 2018 -0800 splice: don't read more than available pipe space In commit 4721a601099, we tried to fix a problem wherein directio reads into a splice pipe will bounce EFAULT/EAGAIN all the way out to userspace by simulating a zero-byte short read. This happens because some directio read implementations (xfs) will call bio_iov_iter_get_pages to grab pipe buffer pages and issue asynchronous reads, but as soon as we run out of pipe buffers that _get_pages call returns EFAULT, which the splice code translates to EAGAIN and bounces out to userspace. In that commit, the iomap code catches the EFAULT and simulates a zero-byte read, but that causes assertion errors on regular splice reads because xfs doesn't allow short directio reads. The brokenness is compounded by splice_direct_to_actor immediately bailing on do_splice_to returning <= 0 without ever calling ->actor (which empties out the pipe), so if userspace calls back we'll EFAULT again on the full pipe, and nothing ever gets copied. Therefore, teach splice_direct_to_actor to clamp its requests to the amount of free space in the pipe and remove the simulated short read from the iomap directio code. Fixes: 4721a601099 ("iomap: dio data corruption and spurious errors when pipes fill") Reported-by: Murphy Zhou Ranted-by: Amir Goldstein Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong Pleaase apply these commits. Best regards. Nobuhiro