From patchwork Wed Nov 7 06:31:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Chinner X-Patchwork-Id: 10671903 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 7D1D315E9 for ; Wed, 7 Nov 2018 06:32:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6F3CC2B64D for ; Wed, 7 Nov 2018 06:32:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 642832B77D; Wed, 7 Nov 2018 06:32:20 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, 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 08EA82B64D for ; Wed, 7 Nov 2018 06:32:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728246AbeKGQBO (ORCPT ); Wed, 7 Nov 2018 11:01:14 -0500 Received: from ipmail03.adl2.internode.on.net ([150.101.137.141]:1838 "EHLO ipmail03.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726604AbeKGQBO (ORCPT ); Wed, 7 Nov 2018 11:01:14 -0500 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail03.adl2.internode.on.net with ESMTP; 07 Nov 2018 17:01:33 +1030 Received: from discord.disaster.area ([192.168.1.111]) by dastard with esmtp (Exim 4.80) (envelope-from ) id 1gKHNE-00086l-3R; Wed, 07 Nov 2018 17:31:32 +1100 Received: from dave by discord.disaster.area with local (Exim 4.91) (envelope-from ) id 1gKHNE-0001j4-2O; Wed, 07 Nov 2018 17:31:32 +1100 From: Dave Chinner To: linux-xfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Subject: [PATCH 10/16] iomap: enable zero-around for iomap_zero_range() Date: Wed, 7 Nov 2018 17:31:21 +1100 Message-Id: <20181107063127.3902-11-david@fromorbit.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181107063127.3902-1-david@fromorbit.com> References: <20181107063127.3902-1-david@fromorbit.com> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Dave Chinner iomap_zero_range() is used to zero the range between the old EOF and the new EOF when the file is truncated up or written beyond the existing EOF. With block size larger than page size, we can't assume that because we've mapped a hole or an unwritten extent that there is no data needing to be written in the portion of the block inside the old EOF. Hence we need to zero to closer of the end of the block or the new EOF so that subsequent reads of the range between the old and new EOF are do not expose stale data. Signed-off-by: Dave Chinner --- fs/iomap.c | 45 +++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 41 insertions(+), 4 deletions(-) diff --git a/fs/iomap.c b/fs/iomap.c index 56f40177ed17..d572e57c5caa 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -780,7 +780,14 @@ static int iomap_zero(struct inode *inode, loff_t pos, unsigned offset, if (status) return status; - zero_user(page, offset, bytes); + /* + * zero-around is conditional on whether the page we found already + * contains data or not. If it's up to date, it contains data and we + * should not zero it. We still need to mark it dirty to get that data + * written, however. + */ + if (!(iomap->flags & IOMAP_F_ZERO_AROUND) || !PageUptodate(page)) + zero_user(page, offset, bytes); mark_page_accessed(page); return iomap_write_end(inode, pos, bytes, bytes, page, iomap); @@ -877,11 +884,41 @@ iomap_zero_range_actor(struct inode *inode, loff_t pos, loff_t count, { bool *did_zero = data; loff_t written = 0; + loff_t old_count = 0; int status; /* already zeroed? we're done. */ - if (iomap->type == IOMAP_HOLE || iomap->type == IOMAP_UNWRITTEN) - return count; + if (iomap->type == IOMAP_HOLE || iomap->type == IOMAP_UNWRITTEN) { + + if (!iomap_need_zero_around(iomap)) + return count; + + /* + * Because we landed in a hole, we only need to zero to the end + * of this block. We'll do that by the loop below, but we need + * to trim count here so the zero-around only acts on this + * block, too. + * + * The magic "pos + 1" is needed because we want the offset of + * the next block after pos. If pos is already aligned to the + * block size, the round_up() returns the same value, not that + * of the next highest multiple. Hence we have to add 1 to pos + * to get round_up() to behave as we want. + */ + old_count = count; + if (pos + count > round_up(pos + 1, i_blocksize(inode))) + count = round_up(pos + 1, i_blocksize(inode)) - pos; + + status = iomap_zero_around(inode, pos, count, iomap); + if (status) + return status; + + /* + * now clear the zero-around flag so that the range requested + * in this block will be unconditionally zeroed. + */ + iomap->flags &= ~IOMAP_F_ZERO_AROUND; + } do { unsigned offset, bytes; @@ -903,7 +940,7 @@ iomap_zero_range_actor(struct inode *inode, loff_t pos, loff_t count, *did_zero = true; } while (count > 0); - return written; + return old_count ? old_count : written; } int