From patchwork Fri Nov 16 19:07:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 10686897 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1487814D6 for ; Fri, 16 Nov 2018 19:07:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 04E172D78B for ; Fri, 16 Nov 2018 19:07:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EB2872D870; Fri, 16 Nov 2018 19:07:32 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY 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 88A802D78B for ; Fri, 16 Nov 2018 19:07:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725854AbeKQFVI (ORCPT ); Sat, 17 Nov 2018 00:21:08 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:42950 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725729AbeKQFVI (ORCPT ); Sat, 17 Nov 2018 00:21:08 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wAGJ3vZV071531; Fri, 16 Nov 2018 19:07:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : mime-version : content-type; s=corp-2018-07-02; bh=uZqoQ6Y/X8yttx7RtlYulIgq2S6fm3CNgA+wyDs/ARo=; b=cyXU5+FNM3u7uJIt2yyhxyrESv+z5iKQv/eolvA/utzk1TjRvaVtwiPCWOy1Wpr/WnuC uQaVlOl9yMYMSCqD+iU/O48Vm3iFbIjGeWeqK7NaV/lXVR/hsBhbbqE2IQiPl3gNryGT 7hR6S4DffLRgiVm7Xw2jePGsCc7Wtk9vNVF3RhIprJThfGRUUHlx8CYWgc2RspjORn9A Xbr77cKZE57VA3FUfKILKd5O0P4SSpzlDMGgxbp5/hKh/It3IhbPkF69Ps0FFR+TKe1I fz9FeN+/MX6iAKEVlB30azNJO7n18BCQnL3A288ZldeZNOUwaXLdlQLfg7gpZGn7KqLX Rw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2nr7csgtkm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Nov 2018 19:07:27 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAGJ7PCn006175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Nov 2018 19:07:26 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wAGJ7PI5030903; Fri, 16 Nov 2018 19:07:25 GMT Received: from localhost (/67.169.218.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2018 11:07:25 -0800 Date: Fri, 16 Nov 2018 11:07:24 -0800 From: "Darrick J. Wong" To: Brian Foster , Dave Chinner Cc: xfs Subject: [RFC PATCH] xfs: flush posteof zeroing before reflink truncation Message-ID: <20181116190724.GW4235@magnolia> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9079 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=896 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811160168 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 From: Darrick J. Wong If we're remapping into a range that starts beyond EOF, we have to zero the memory between EOF and the start of the target range, as established in 410fdc72b05af. However, in 4918ef4ea008, we extended the pagecache truncation range downwards to a page boundary to guarantee that pagecache pages are removed and that there's no possibility that we end up zeroing subpage blocks within a page. Unfortunately, we never commit the posteof zeroing to disk, so on a filesystem where page size > block size the truncation partially undoes the zeroing and we end up with stale disk contents. Brian and I reproduced this problem by running generic/091 on a 1k block xfs filesystem, assuming fsx in fstests supports clone/dedupe/copyrange. Fixes: 410fdc72b05a ("xfs: zero posteof blocks when cloning above eof") Fixes: 4918ef4ea008 ("xfs: fix pagecache truncation prior to reflink") Simultaneously-diagnosed-by: Brian Foster Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster --- Note: I haven't tested this thoroughly but wanted to push this out for everyone to look at ASAP. --- fs/xfs/xfs_reflink.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index c56bdbfcf7ae..8ea09a7e550c 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -1255,13 +1255,19 @@ xfs_reflink_zero_posteof( loff_t pos) { loff_t isize = i_size_read(VFS_I(ip)); + int error; if (pos <= isize) return 0; trace_xfs_zero_eof(ip, isize, pos - isize); - return iomap_zero_range(VFS_I(ip), isize, pos - isize, NULL, + error = iomap_zero_range(VFS_I(ip), isize, pos - isize, NULL, &xfs_iomap_ops); + if (error) + return error; + + return filemap_write_and_wait_range(VFS_I(ip)->i_mapping, + isize, pos - 1); } /*