From nobody Mon Feb 9 10:51:51 2026 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBB4B3C478; Mon, 11 Mar 2024 12:30:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160204; cv=none; b=bp6BY4FjQMrfRG+phscCH1G/bFgznIO/qjIYc1oLkaBstZVdWB8TzM8b4ovjdXyz3Cv4v1dtv0LnZNSNwReHBQ7nij3uXmck0xAICEK67PeF32z5yjXy7bbsyVXfq+Wo3sywK+OK7XcwEQb1Rqbw28bnlo1O9CNraqwkyi2qLXI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160204; c=relaxed/simple; bh=5x2jUS69btnG358xEvklJtqtctnoWjAA0CGJVtMNkbQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=CeVdfWxov47fEDVYvm0eNW7qBG2T+ni7ZiLw+nloJ8HR7G//A/NqfTeDX3JdThmyoAfwDJN+s6bXY+Nu70LtSQVoZ3h00enSUHqeU4eLY3gIhpzRvKwOcJIomK6d/vpbrjtZMgvUqjzd5c8tMtm9SFvZlBmyloLnLsaqTxSR0/Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4Ttbh20n6Wz4f3jZd; Mon, 11 Mar 2024 20:29:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id B80821A01A7; Mon, 11 Mar 2024 20:29:57 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgDHlxAt+e5lAE9+Gg--.62739S5; Mon, 11 Mar 2024 20:29:57 +0800 (CST) From: Zhang Yi To: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, djwong@kernel.org, hch@infradead.org, brauner@kernel.org, david@fromorbit.com, tytso@mit.edu, jack@suse.cz, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yukuai3@huawei.com Subject: [PATCH 1/4] xfs: match lock mode in xfs_buffered_write_iomap_begin() Date: Mon, 11 Mar 2024 20:22:52 +0800 Message-Id: <20240311122255.2637311-2-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> References: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: cCh0CgDHlxAt+e5lAE9+Gg--.62739S5 X-Coremail-Antispam: 1UD129KBjvJXoW7KF43tw1xXrW7trWrAryUtrb_yoW8ZF17pr n7K3yDG392qrn0vr10qryYyr1Ik3W7Jw18Ar15Wa93uw1ktr4xKr4093WrC3W8JrsFy34v gF4UGr1kua43AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBK14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2AI xVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20x vE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xv r2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2IY04 v7MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_ Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x 0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8 JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIx AIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7VUjA9NDUUUUU= = X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Commit 1aa91d9c9933 ("xfs: Add async buffered write support") replace xfs_ilock(XFS_ILOCK_EXCL) with xfs_ilock_for_iomap() when locking the writing inode, and a new variable lockmode is used to indicate the lock mode. Although the lockmode should always be XFS_ILOCK_EXCL, it's still better to use this variable instead of useing XFS_ILOCK_EXCL directly when unlocking the inode. Fixes: 1aa91d9c9933 ("xfs: Add async buffered write support") Signed-off-by: Zhang Yi Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong --- fs/xfs/xfs_iomap.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 18c8f168b153..ccf83e72d8ca 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -1149,13 +1149,13 @@ xfs_buffered_write_iomap_begin( * them out if the write happens to fail. */ seq =3D xfs_iomap_inode_sequence(ip, IOMAP_F_NEW); - xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_iunlock(ip, lockmode); trace_xfs_iomap_alloc(ip, offset, count, allocfork, &imap); return xfs_bmbt_to_iomap(ip, iomap, &imap, flags, IOMAP_F_NEW, seq); =20 found_imap: seq =3D xfs_iomap_inode_sequence(ip, 0); - xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_iunlock(ip, lockmode); return xfs_bmbt_to_iomap(ip, iomap, &imap, flags, 0, seq); =20 found_cow: @@ -1165,17 +1165,17 @@ xfs_buffered_write_iomap_begin( if (error) goto out_unlock; seq =3D xfs_iomap_inode_sequence(ip, IOMAP_F_SHARED); - xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_iunlock(ip, lockmode); return xfs_bmbt_to_iomap(ip, iomap, &cmap, flags, IOMAP_F_SHARED, seq); } =20 xfs_trim_extent(&cmap, offset_fsb, imap.br_startoff - offset_fsb); - xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_iunlock(ip, lockmode); return xfs_bmbt_to_iomap(ip, iomap, &cmap, flags, 0, seq); =20 out_unlock: - xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_iunlock(ip, lockmode); return error; } =20 --=20 2.39.2 From nobody Mon Feb 9 10:51:51 2026 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4032239AE3; Mon, 11 Mar 2024 12:30:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160204; cv=none; b=OQswMvSaTvVqHzxMV05LXmylbAKRh8VPUTDLXnS5n93EpgUJz7nFP9jG/pFgCNOpYyJAIEWXKzGa7fc6cCLADPQSS7YAwOgLLoowuUkbLksmPxoSZ0gdcCLWuRICbYams198Pa7fBDA5kZ+4AM3HQXi04nQHwKdNaK/nB2Eiu+M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160204; c=relaxed/simple; bh=rXLAzQ+ucmDQz9YniwFLAZ4a/zSlJaidZ4o+lEJyuPo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=JGYiiECIJsvJGfHcNpXnM559AcI4LdzsNy+/Vl43ALdL5d1GuMSrI9RGTXCtlI3+WJzUu9rob8sgXOCkfgVivu2klk2XCFltJclHx8lqPfAmyhs4NFu3Cm1dovBk4kopIE5k8GIxL42idDvWocat1x4UYz/1ijQiN/40PHuqOdg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4Ttbgy4Zwsz4f3lgD; Mon, 11 Mar 2024 20:29:50 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 4A8261A0172; Mon, 11 Mar 2024 20:29:58 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgDHlxAt+e5lAE9+Gg--.62739S6; Mon, 11 Mar 2024 20:29:58 +0800 (CST) From: Zhang Yi To: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, djwong@kernel.org, hch@infradead.org, brauner@kernel.org, david@fromorbit.com, tytso@mit.edu, jack@suse.cz, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yukuai3@huawei.com Subject: [PATCH 2/4] xfs: convert delayed extents to unwritten when zeroing post eof blocks Date: Mon, 11 Mar 2024 20:22:53 +0800 Message-Id: <20240311122255.2637311-3-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> References: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: cCh0CgDHlxAt+e5lAE9+Gg--.62739S6 X-Coremail-Antispam: 1UD129KBjvJXoWxGw4ktry7GF4Utw4UurW8Crg_yoW5tFW8pF Z3Kwn8Grs3Gw1avws3AFn8Ww1Fvwn5Cw48Xry3Wwn3Xas8tr42ga4xA3WYgw18Gwsay3ZF 9F4YgFyI9w1UZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBK14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2AI xVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20x vE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xv r2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2IY04 v7MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_ Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x 0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8 JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIx AIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7VU1489tUUUUU= = X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Current clone operation could be non-atomic if the destination of a file is beyond EOF, user could get a file with corrupted (zeroed) data on crash. The problem is about to pre-alloctions. If you write some data into a file [A, B) (the position letters are increased one by one), and xfs could pre-allocate some blocks, then we get a delayed extent [A, D). Then the writeback path allocate blocks and convert this delayed extent [A, C) since lack of enough contiguous physical blocks, so the extent [C, D) is still delayed. After that, both the in-memory and the on-disk file size are B. If we clone file range into [E, F) from another file, xfs_reflink_zero_posteof() would call iomap_zero_range() to zero out the range [B, E) beyond EOF and flush range. Since [C, D) is still a delayed extent, it will be zeroed and the file's in-memory && on-disk size will be updated to D after flushing and before doing the clone operation. This is wrong, because user can user can see the size change and read zeros in the middle of the clone operation. We need to keep the in-memory and on-disk size before the clone operation starts, so instead of writing zeroes through the page cache for delayed ranges beyond EOF, we convert these ranges to unwritten and invalidating any cached data over that range beyond EOF. Suggested-by: Dave Chinner Signed-off-by: Zhang Yi --- fs/xfs/xfs_iomap.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index ccf83e72d8ca..2b2aace25355 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -957,6 +957,7 @@ xfs_buffered_write_iomap_begin( struct xfs_mount *mp =3D ip->i_mount; xfs_fileoff_t offset_fsb =3D XFS_B_TO_FSBT(mp, offset); xfs_fileoff_t end_fsb =3D xfs_iomap_end_fsb(mp, offset, count); + xfs_fileoff_t eof_fsb =3D XFS_B_TO_FSBT(mp, XFS_ISIZE(ip)); struct xfs_bmbt_irec imap, cmap; struct xfs_iext_cursor icur, ccur; xfs_fsblock_t prealloc_blocks =3D 0; @@ -1035,6 +1036,22 @@ xfs_buffered_write_iomap_begin( } =20 if (imap.br_startoff <=3D offset_fsb) { + /* + * For zeroing out delayed allocation extent, we trim it if + * it's partial beyonds EOF block, or convert it to unwritten + * extent if it's all beyonds EOF block. + */ + if ((flags & IOMAP_ZERO) && + isnullstartblock(imap.br_startblock)) { + if (offset_fsb > eof_fsb) + goto convert_delay; + if (end_fsb > eof_fsb) { + end_fsb =3D eof_fsb + 1; + xfs_trim_extent(&imap, offset_fsb, + end_fsb - offset_fsb); + } + } + /* * For reflink files we may need a delalloc reservation when * overwriting shared extents. This includes zeroing of @@ -1158,6 +1175,18 @@ xfs_buffered_write_iomap_begin( xfs_iunlock(ip, lockmode); return xfs_bmbt_to_iomap(ip, iomap, &imap, flags, 0, seq); =20 +convert_delay: + end_fsb =3D min(end_fsb, imap.br_startoff + imap.br_blockcount); + xfs_iunlock(ip, lockmode); + truncate_pagecache_range(inode, offset, XFS_FSB_TO_B(mp, end_fsb)); + error =3D xfs_iomap_write_direct(ip, offset_fsb, end_fsb - offset_fsb, + flags, &imap, &seq); + if (error) + return error; + + trace_xfs_iomap_alloc(ip, offset, count, XFS_DATA_FORK, &imap); + return xfs_bmbt_to_iomap(ip, iomap, &imap, flags, IOMAP_F_NEW, seq); + found_cow: seq =3D xfs_iomap_inode_sequence(ip, 0); if (imap.br_startoff <=3D offset_fsb) { --=20 2.39.2 From nobody Mon Feb 9 10:51:51 2026 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 402A0383A4; Mon, 11 Mar 2024 12:30:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160205; cv=none; b=W6M+0+XBwoW3rlHbH1myph7OJeNaChZZIBwmA0KUEQheGr8dN1zVzrhXOQlM18HwTKm4QvmZTUUcg8NzkLYYcq2B2qRP2rrtmWvdZbHiHNOhrKStyYRIjlN6OINymxXI/95hKmu/Az5tI7vIWVMNEqUWzCpGpnPk3fURW4FE5Dc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160205; c=relaxed/simple; bh=/YSJHjj7P48+t3yJnDuYkKpzjQlsCrX2SUkLiFTSPKE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IsCc7Q57eJtsWcXPZEeIhLYu8X7FenwkAF6uGl1eLjkBHVplyzuDvh0+gksKKp1jzohp66wLY+h4zs8tXfPhfwfrGr4VNn7TjTnC+4dbWk+Q0GyuMPxRmmCESaDdqeeEcmhnxr4sRRuQOBRlLidn/sUTOvImJXfvQef7rsoQO5s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4Ttbh31Vzlz4f3jkk; Mon, 11 Mar 2024 20:29:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id CF65A1A0172; Mon, 11 Mar 2024 20:29:58 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgDHlxAt+e5lAE9+Gg--.62739S7; Mon, 11 Mar 2024 20:29:58 +0800 (CST) From: Zhang Yi To: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, djwong@kernel.org, hch@infradead.org, brauner@kernel.org, david@fromorbit.com, tytso@mit.edu, jack@suse.cz, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yukuai3@huawei.com Subject: [PATCH 3/4] iomap: don't increase i_size if it's not a write operation Date: Mon, 11 Mar 2024 20:22:54 +0800 Message-Id: <20240311122255.2637311-4-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> References: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: cCh0CgDHlxAt+e5lAE9+Gg--.62739S7 X-Coremail-Antispam: 1UD129KBjvJXoWxZrWkXr13tryfAFy8CFWrGrg_yoW7Jr1fpr ZFk3yDCan7JF47Wrn5JF98ZryYkFyrKrW7Cry7G3y3ZFn0yr17K3WrGa4YvF98J3s3Ar4f tF4kAa4rWF1UCr7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPj14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v2 6r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2 Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_ Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8Jw CI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjfUFfHUDUUU U X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Increase i_size in iomap_zero_range() and iomap_unshare_iter() is not needed, the caller should handle it. Especially, when truncate partial block, we could not increase i_size beyond the new EOF here. It doesn't affect xfs and gfs2 now because they set the new file size after zero out, it doesn't matter that a transient increase in i_size, but it will affect ext4 because it set file size before truncate. At the same time, iomap_write_failed() is also not needed for above two cases too, so factor them out and move them to iomap_write_iter() and iomap_zero_iter(). Signed-off-by: Zhang Yi --- fs/iomap/buffered-io.c | 59 +++++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 093c4515b22a..19f91324c690 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -786,7 +786,6 @@ static int iomap_write_begin(struct iomap_iter *iter, l= off_t pos, =20 out_unlock: __iomap_put_folio(iter, pos, 0, folio); - iomap_write_failed(iter->inode, pos, len); =20 return status; } @@ -838,34 +837,13 @@ static size_t iomap_write_end(struct iomap_iter *iter= , loff_t pos, size_t len, size_t copied, struct folio *folio) { const struct iomap *srcmap =3D iomap_iter_srcmap(iter); - loff_t old_size =3D iter->inode->i_size; - size_t ret; - - if (srcmap->type =3D=3D IOMAP_INLINE) { - ret =3D iomap_write_end_inline(iter, folio, pos, copied); - } else if (srcmap->flags & IOMAP_F_BUFFER_HEAD) { - ret =3D block_write_end(NULL, iter->inode->i_mapping, pos, len, - copied, &folio->page, NULL); - } else { - ret =3D __iomap_write_end(iter->inode, pos, len, copied, folio); - } =20 - /* - * Update the in-memory inode size after copying the data into the page - * cache. It's up to the file system to write the updated size to disk, - * preferably after I/O completion so that no stale data is exposed. - */ - if (pos + ret > old_size) { - i_size_write(iter->inode, pos + ret); - iter->iomap.flags |=3D IOMAP_F_SIZE_CHANGED; - } - __iomap_put_folio(iter, pos, ret, folio); - - if (old_size < pos) - pagecache_isize_extended(iter->inode, old_size, pos); - if (ret < len) - iomap_write_failed(iter->inode, pos + ret, len - ret); - return ret; + if (srcmap->type =3D=3D IOMAP_INLINE) + return iomap_write_end_inline(iter, folio, pos, copied); + if (srcmap->flags & IOMAP_F_BUFFER_HEAD) + return block_write_end(NULL, iter->inode->i_mapping, pos, len, + copied, &folio->page, NULL); + return __iomap_write_end(iter->inode, pos, len, copied, folio); } =20 static loff_t iomap_write_iter(struct iomap_iter *iter, struct iov_iter *i) @@ -880,6 +858,7 @@ static loff_t iomap_write_iter(struct iomap_iter *iter,= struct iov_iter *i) =20 do { struct folio *folio; + loff_t old_size; size_t offset; /* Offset into folio */ size_t bytes; /* Bytes to write to folio */ size_t copied; /* Bytes copied from user */ @@ -912,8 +891,10 @@ static loff_t iomap_write_iter(struct iomap_iter *iter= , struct iov_iter *i) } =20 status =3D iomap_write_begin(iter, pos, bytes, &folio); - if (unlikely(status)) + if (unlikely(status)) { + iomap_write_failed(iter->inode, pos, bytes); break; + } if (iter->iomap.flags & IOMAP_F_STALE) break; =20 @@ -927,6 +908,24 @@ static loff_t iomap_write_iter(struct iomap_iter *iter= , struct iov_iter *i) copied =3D copy_folio_from_iter_atomic(folio, offset, bytes, i); status =3D iomap_write_end(iter, pos, bytes, copied, folio); =20 + /* + * Update the in-memory inode size after copying the data into + * the page cache. It's up to the file system to write the + * updated size to disk, preferably after I/O completion so that + * no stale data is exposed. + */ + old_size =3D iter->inode->i_size; + if (pos + status > old_size) { + i_size_write(iter->inode, pos + status); + iter->iomap.flags |=3D IOMAP_F_SIZE_CHANGED; + } + __iomap_put_folio(iter, pos, status, folio); + + if (old_size < pos) + pagecache_isize_extended(iter->inode, old_size, pos); + if (status < bytes) + iomap_write_failed(iter->inode, pos + status, + bytes - status); if (unlikely(copied !=3D status)) iov_iter_revert(i, copied - status); =20 @@ -1296,6 +1295,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *i= ter) bytes =3D folio_size(folio) - offset; =20 bytes =3D iomap_write_end(iter, pos, bytes, bytes, folio); + __iomap_put_folio(iter, pos, bytes, folio); if (WARN_ON_ONCE(bytes =3D=3D 0)) return -EIO; =20 @@ -1360,6 +1360,7 @@ static loff_t iomap_zero_iter(struct iomap_iter *iter= , bool *did_zero) folio_mark_accessed(folio); =20 bytes =3D iomap_write_end(iter, pos, bytes, bytes, folio); + __iomap_put_folio(iter, pos, bytes, folio); if (WARN_ON_ONCE(bytes =3D=3D 0)) return -EIO; =20 --=20 2.39.2 From nobody Mon Feb 9 10:51:51 2026 Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAB463C699; Mon, 11 Mar 2024 12:30:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160205; cv=none; b=NVrYIcggKAGwMvPYeEGVYT24dgbmOAkM7cQi4aVHZfJH87pDXwVaj7jaS4xdQoRO4lLDOywHRWFzz4yxRmFuHslL/YcPpDLDfkrs0n9ozbmTB7llqXERa7hdELr/F/XdP89I6rPXLZ2cGafaL0xPYNlbsi+fRZzf2S/102Z3Pj4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710160205; c=relaxed/simple; bh=ERGB+uRnYTuNnKGc+MsbXEt6gLbLEGXQxvrvJ4rByP4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=fPKGWLMa1pzCDByNOry03OmtVn21SPhtDmtOqM87onYyA//eiqIuZRLu23IbBbO8p0R5a7embvjLhp817MJ6G01I1/KsvdRiLkLwK/DSst1hvVKMbwupiIWJrw6HqOst+PtGi9vs1aq1tAaxtGbeQoiskCihOQa9XrNcGPoUu9Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4Ttbh15Kgqz4f3jR9; Mon, 11 Mar 2024 20:29:53 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 5ECD61A016E; Mon, 11 Mar 2024 20:29:59 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgDHlxAt+e5lAE9+Gg--.62739S8; Mon, 11 Mar 2024 20:29:59 +0800 (CST) From: Zhang Yi To: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, djwong@kernel.org, hch@infradead.org, brauner@kernel.org, david@fromorbit.com, tytso@mit.edu, jack@suse.cz, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yukuai3@huawei.com Subject: [PATCH 4/4] iomap: cleanup iomap_write_iter() Date: Mon, 11 Mar 2024 20:22:55 +0800 Message-Id: <20240311122255.2637311-5-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> References: <20240311122255.2637311-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: cCh0CgDHlxAt+e5lAE9+Gg--.62739S8 X-Coremail-Antispam: 1UD129KBjvJXoWxXF4UAr48KF43urWfZF1DZFb_yoW5tr17p3 45Ka95CrW8Xw47Wrn5JFy5WFyYkFyfKFW7GryUGwsIvFn0yrZ8KF18WayYv3W5Jas3Ar4f tF4vyryrGF1UAr7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPF14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjfUF18B UUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The status variable in iomap_write_iter() is confusing and iomap_write_end() always return 0 or copied bytes, so replace it with a new written variable to represent the written bytes in each cycle, and also do some cleanup, no logic changes. Signed-off-by: Zhang Yi --- fs/iomap/buffered-io.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 19f91324c690..767af6e67ed4 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -851,7 +851,7 @@ static loff_t iomap_write_iter(struct iomap_iter *iter,= struct iov_iter *i) loff_t length =3D iomap_length(iter); size_t chunk =3D PAGE_SIZE << MAX_PAGECACHE_ORDER; loff_t pos =3D iter->pos; - ssize_t written =3D 0; + ssize_t total_written =3D 0; long status =3D 0; struct address_space *mapping =3D iter->inode->i_mapping; unsigned int bdp_flags =3D (iter->flags & IOMAP_NOWAIT) ? BDP_ASYNC : 0; @@ -862,6 +862,7 @@ static loff_t iomap_write_iter(struct iomap_iter *iter,= struct iov_iter *i) size_t offset; /* Offset into folio */ size_t bytes; /* Bytes to write to folio */ size_t copied; /* Bytes copied from user */ + size_t written; /* Bytes have been written */ =20 bytes =3D iov_iter_count(i); retry: @@ -906,7 +907,7 @@ static loff_t iomap_write_iter(struct iomap_iter *iter,= struct iov_iter *i) flush_dcache_folio(folio); =20 copied =3D copy_folio_from_iter_atomic(folio, offset, bytes, i); - status =3D iomap_write_end(iter, pos, bytes, copied, folio); + written =3D iomap_write_end(iter, pos, bytes, copied, folio); =20 /* * Update the in-memory inode size after copying the data into @@ -915,28 +916,26 @@ static loff_t iomap_write_iter(struct iomap_iter *ite= r, struct iov_iter *i) * no stale data is exposed. */ old_size =3D iter->inode->i_size; - if (pos + status > old_size) { - i_size_write(iter->inode, pos + status); + if (pos + written > old_size) { + i_size_write(iter->inode, pos + written); iter->iomap.flags |=3D IOMAP_F_SIZE_CHANGED; } - __iomap_put_folio(iter, pos, status, folio); + __iomap_put_folio(iter, pos, written, folio); =20 if (old_size < pos) pagecache_isize_extended(iter->inode, old_size, pos); - if (status < bytes) - iomap_write_failed(iter->inode, pos + status, - bytes - status); - if (unlikely(copied !=3D status)) - iov_iter_revert(i, copied - status); =20 cond_resched(); - if (unlikely(status =3D=3D 0)) { + if (unlikely(written =3D=3D 0)) { /* * A short copy made iomap_write_end() reject the * thing entirely. Might be memory poisoning * halfway through, might be a race with munmap, * might be severe memory pressure. */ + iomap_write_failed(iter->inode, pos, bytes); + iov_iter_revert(i, copied); + if (chunk > PAGE_SIZE) chunk /=3D 2; if (copied) { @@ -944,17 +943,17 @@ static loff_t iomap_write_iter(struct iomap_iter *ite= r, struct iov_iter *i) goto retry; } } else { - pos +=3D status; - written +=3D status; - length -=3D status; + pos +=3D written; + total_written +=3D written; + length -=3D written; } } while (iov_iter_count(i) && length); =20 if (status =3D=3D -EAGAIN) { - iov_iter_revert(i, written); + iov_iter_revert(i, total_written); return -EAGAIN; } - return written ? written : status; + return total_written ? total_written : status; } =20 ssize_t --=20 2.39.2