From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 84DFD3815FE; Mon, 11 May 2026 07:28:27 +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=1778484510; cv=none; b=igEKUiUC/I8jb13RbT92fbOlKqtiGON54mmyASSg37eRDpnQUOqFiWd2G4GGzEncYmmunr5ZlY8ELoslGsDTGvPmwCLiBvm1Cya6CSIH+gIs7/Fo9+cANlOf0H+TWDbnnMWMyMeeCGwYBWXmRCUYhzMZw7e6M17qyAs+z2Pw0mM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484510; c=relaxed/simple; bh=OGMBpPyaow+gJIEij8UMq76ggdRYF2wiiOdFP8IUo3o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cs/XwuOw85ONk8HJmWRlbBVMABavksxulApiljlOivFEux2z0ujPyk9O1+l94PNq7uKeaINPYQrasIl9hjNi/STAizgmCctJRNQ51qPET7/34ywmXPQCrfZjIlg+f5QXos+/UDtps0Jq/1dLGI3a7ylo1tpilrNMnzUeJdhujE0= 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.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX40RX5zKHMct; Mon, 11 May 2026 15:27:32 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 918CC4056B; Mon, 11 May 2026 15:28:22 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S5; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 01/23] ext4: simplify size updating in ext4_setattr() Date: Mon, 11 May 2026 15:23:21 +0800 Message-ID: <20260511072344.191271-2-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S5 X-Coremail-Antispam: 1UD129KBjvJXoW7Aw4rtrWrZw1kAw1rXw18Krg_yoW8tF4DpF yakw1vkw10gF1q9rn2gF1UZa40qa1093yUXFWjkw40qF1DC3ZaqF17t3y3uFW8trWDWw4Y qF4kKr4rJw1UGrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JU4OJ5UUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The logic for updating the file size in ext4_setattr() is currently somewhat messy. By directly entering the error-handling path after failing to add an orphan inode, the unnecessary recovery process involving old_disksize and the file size can be avoided. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index c2c2d6ac7f3d..0751dc55e94f 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5953,7 +5953,6 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dent= ry *dentry, if (attr->ia_valid & ATTR_SIZE) { handle_t *handle; loff_t oldsize =3D inode->i_size; - loff_t old_disksize; int shrink =3D (attr->ia_size < inode->i_size); =20 if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) { @@ -6037,6 +6036,8 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dent= ry *dentry, if (ext4_handle_valid(handle) && shrink) { error =3D ext4_orphan_add(handle, inode); orphan =3D 1; + if (error) + goto out_handle; } =20 if (shrink) @@ -6052,23 +6053,18 @@ int ext4_setattr(struct mnt_idmap *idmap, struct de= ntry *dentry, (attr->ia_size > 0 ? attr->ia_size - 1 : 0) >> inode->i_sb->s_blocksize_bits); =20 - down_write(&EXT4_I(inode)->i_data_sem); - old_disksize =3D EXT4_I(inode)->i_disksize; - EXT4_I(inode)->i_disksize =3D attr->ia_size; - /* * We have to update i_size under i_data_sem together * with i_disksize to avoid races with writeback code - * running ext4_wb_update_i_disksize(). + * updating disksize in mpage_map_and_submit_extent(). */ - if (!error) - i_size_write(inode, attr->ia_size); - else - EXT4_I(inode)->i_disksize =3D old_disksize; + down_write(&EXT4_I(inode)->i_data_sem); + i_size_write(inode, attr->ia_size); + EXT4_I(inode)->i_disksize =3D attr->ia_size; up_write(&EXT4_I(inode)->i_data_sem); - rc =3D ext4_mark_inode_dirty(handle, inode); - if (!error) - error =3D rc; + + error =3D ext4_mark_inode_dirty(handle, inode); +out_handle: ext4_journal_stop(handle); if (error) goto out_mmap_sem; --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 0571337106A; Mon, 11 May 2026 07:28:25 +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=1778484509; cv=none; b=k3hM+SYLnsxNB1p6MWXAND5vweEAiy8XEDcjQDUmwDDSGpHYQT/OHYC3HI8x4MRBZA73Vqf+ifA/NdR81pgkq+2c7/lv5nXibHkgg67EpYj3/T5lvsheCfwSqKCKM29letkFgis8NmdSVItJwUqDJjr9z7Gp1cAM8C/wPQbsARQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484509; c=relaxed/simple; bh=fSCI/8fINCMTfAZoU8yjJRZCk0VfbmKLq13ONHksVvk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lgWmvBeZDJXC4nDQZxOg1/FLUuzyTTNNOzpk3gHmJZHdiIOELWvvoZJR9nmxcKeFmZWMgI/03QlGiFb+sIJf6jtG2oaXrlcGcHQ6S3xZB+LBxEaK7EldbnMhT23pB8EJgmSwlgY6WtHz9dNFCTcebQyU/X5WkzvZtAEbfzZaIGg= 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.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX40qmvzKHMcw; Mon, 11 May 2026 15:27:32 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id A023D4056E; Mon, 11 May 2026 15:28:22 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S6; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 02/23] ext4: factor out ext4_truncate_[up|down]() Date: Mon, 11 May 2026 15:23:22 +0800 Message-ID: <20260511072344.191271-3-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S6 X-Coremail-Antispam: 1UD129KBjvJXoW3WF48KF4rArWUKFyrGryUZFb_yoWxZryUpF W2k34Fkw18uFyDWF4Iqr4UZF45ta18K3yUGFy2krZ2v3Wqyw1ftF1xt3yrKFWUKr4DWw4j qF4Dtrs3Gw4kJ3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JUQXo7UUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Refactor ext4_setattr() by introducing two helper functions, ext4_truncate_up() and ext4_truncate_down(), to handle size changes. The current ATTR_SIZE processing consolidates checks for both shrinking and non-shrinking cases, leading to cluttered code. Separating the truncation paths improves readability. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 199 +++++++++++++++++++++++++++--------------------- 1 file changed, 112 insertions(+), 87 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 0751dc55e94f..35e958f89bd5 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5855,6 +5855,112 @@ static void ext4_wait_for_tail_page_commit(struct i= node *inode) } } =20 +/* + * Set i_size and i_disksize to 'newsize'. + * + * Both i_rwsem and i_data_sem are required here to avoid races between + * generic append writeback and concurrent truncate that also modify + * i_size and i_disksize. + */ +static inline void ext4_set_inode_size(struct inode *inode, loff_t newsize) +{ + WARN_ON_ONCE(S_ISREG(inode->i_mode) && !inode_is_locked(inode)); + + down_write(&EXT4_I(inode)->i_data_sem); + i_size_write(inode, newsize); + EXT4_I(inode)->i_disksize =3D newsize; + up_write(&EXT4_I(inode)->i_data_sem); +} + +static int ext4_truncate_up(struct inode *inode, loff_t oldsize, loff_t ne= wsize) +{ + ext4_lblk_t old_lblk, new_lblk; + handle_t *handle; + int ret; + + if (!IS_ALIGNED(oldsize | newsize, i_blocksize(inode))) { + ret =3D ext4_inode_attach_jinode(inode); + if (ret) + return ret; + } + + inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode)); + if (!IS_ALIGNED(oldsize, i_blocksize(inode))) { + ret =3D ext4_block_zero_eof(inode, oldsize, LLONG_MAX); + if (ret) + return ret; + } + + handle =3D ext4_journal_start(inode, EXT4_HT_INODE, 3); + if (IS_ERR(handle)) + return PTR_ERR(handle); + + old_lblk =3D oldsize > 0 ? (oldsize - 1) >> inode->i_blkbits : 0; + new_lblk =3D newsize > 0 ? (newsize - 1) >> inode->i_blkbits : 0; + ext4_fc_track_range(handle, inode, old_lblk, new_lblk); + + ext4_set_inode_size(inode, newsize); + + ret =3D ext4_mark_inode_dirty(handle, inode); + ext4_journal_stop(handle); + if (ret) + return ret; + /* + * isize extend must be called outside an active handle due to + * the lock ordering of transaction start and folio lock in the + * iomap buffered I/O path (folio lock -> transaction start). + */ + pagecache_isize_extended(inode, oldsize, newsize); + return 0; +} + +static int ext4_truncate_down(struct inode *inode, loff_t oldsize, + loff_t newsize, int *orphan) +{ + ext4_lblk_t start_lblk; + handle_t *handle; + int ret; + + /* Do not change i_size. */ + if (newsize =3D=3D oldsize) + goto truncate; + + /* Shrink. */ + handle =3D ext4_journal_start(inode, EXT4_HT_INODE, 3); + if (IS_ERR(handle)) + return PTR_ERR(handle); + + if (ext4_handle_valid(handle)) { + ret =3D ext4_orphan_add(handle, inode); + *orphan =3D 1; + if (ret) { + ext4_journal_stop(handle); + return ret; + } + } + + start_lblk =3D newsize > 0 ? (newsize - 1) >> inode->i_blkbits : 0; + ext4_fc_track_range(handle, inode, start_lblk, EXT_MAX_BLOCKS - 1); + + ext4_set_inode_size(inode, newsize); + + ret =3D ext4_mark_inode_dirty(handle, inode); + ext4_journal_stop(handle); + if (ret) + return ret; + + if (ext4_should_journal_data(inode)) + ext4_wait_for_tail_page_commit(inode); +truncate: + /* + * Truncate pagecache after we've waited for commit in data=3Djournal + * mode to make pages freeable. Call ext4_truncate() even if + * i_size didn't change to truncatea possible preallocated blocks. + */ + truncate_pagecache(inode, newsize); + return ext4_truncate(inode); +} + /* * ext4_setattr() * @@ -5951,7 +6057,6 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dent= ry *dentry, } =20 if (attr->ia_valid & ATTR_SIZE) { - handle_t *handle; loff_t oldsize =3D inode->i_size; int shrink =3D (attr->ia_size < inode->i_size); =20 @@ -6003,94 +6108,14 @@ int ext4_setattr(struct mnt_idmap *idmap, struct de= ntry *dentry, goto err_out; } =20 - if (attr->ia_size !=3D inode->i_size) { - /* attach jbd2 jinode for EOF folio tail zeroing */ - if (attr->ia_size & (inode->i_sb->s_blocksize - 1) || - oldsize & (inode->i_sb->s_blocksize - 1)) { - error =3D ext4_inode_attach_jinode(inode); - if (error) - goto out_mmap_sem; - } - - /* - * Update c/mtime and tail zero the EOF folio on - * truncate up. ext4_truncate() handles the shrink case - * below. - */ - if (!shrink) { - inode_set_mtime_to_ts(inode, - inode_set_ctime_current(inode)); - if (oldsize & (inode->i_sb->s_blocksize - 1)) { - error =3D ext4_block_zero_eof(inode, - oldsize, LLONG_MAX); - if (error) - goto out_mmap_sem; - } - } - - handle =3D ext4_journal_start(inode, EXT4_HT_INODE, 3); - if (IS_ERR(handle)) { - error =3D PTR_ERR(handle); - goto out_mmap_sem; - } - if (ext4_handle_valid(handle) && shrink) { - error =3D ext4_orphan_add(handle, inode); - orphan =3D 1; - if (error) - goto out_handle; - } - - if (shrink) - ext4_fc_track_range(handle, inode, - (attr->ia_size > 0 ? attr->ia_size - 1 : 0) >> - inode->i_sb->s_blocksize_bits, - EXT_MAX_BLOCKS - 1); - else - ext4_fc_track_range( - handle, inode, - (oldsize > 0 ? oldsize - 1 : oldsize) >> - inode->i_sb->s_blocksize_bits, - (attr->ia_size > 0 ? attr->ia_size - 1 : 0) >> - inode->i_sb->s_blocksize_bits); - - /* - * We have to update i_size under i_data_sem together - * with i_disksize to avoid races with writeback code - * updating disksize in mpage_map_and_submit_extent(). - */ - down_write(&EXT4_I(inode)->i_data_sem); - i_size_write(inode, attr->ia_size); - EXT4_I(inode)->i_disksize =3D attr->ia_size; - up_write(&EXT4_I(inode)->i_data_sem); - - error =3D ext4_mark_inode_dirty(handle, inode); -out_handle: - ext4_journal_stop(handle); - if (error) - goto out_mmap_sem; - if (!shrink) { - pagecache_isize_extended(inode, oldsize, - inode->i_size); - } else if (ext4_should_journal_data(inode)) { - ext4_wait_for_tail_page_commit(inode); - } + if (attr->ia_size > oldsize) + error =3D ext4_truncate_up(inode, oldsize, attr->ia_size); + else { + /* Shrink or do not change i_size. */ + error =3D ext4_truncate_down(inode, oldsize, + attr->ia_size, &orphan); } =20 - /* - * Truncate pagecache after we've waited for commit - * in data=3Djournal mode to make pages freeable. - */ - truncate_pagecache(inode, inode->i_size); - /* - * Call ext4_truncate() even if i_size didn't change to - * truncate possible preallocated blocks. - */ - if (attr->ia_size <=3D oldsize) { - rc =3D ext4_truncate(inode); - if (rc) - error =3D rc; - } -out_mmap_sem: filemap_invalidate_unlock(inode->i_mapping); } =20 --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 B1AFA382F28; Mon, 11 May 2026 07:28:33 +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=1778484516; cv=none; b=dEvjKgVAlWQnpdSvHg1OsxrD6zQEVcEKWUMJIZfEKIqTXbeQITCiA+ARMOXF/58YXk9YReLvhJmezkwPLueXpFZNmEXo6wTI0wukcY5lGIfeRzufsdK9EbKLz1LOF4iCvDwbsmE5eMgRTWa8zYxQtS9cgK00OuHs2MCnIxizTL8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484516; c=relaxed/simple; bh=ZGKx46dogqEsmAMWIMKLQxCHSYqNgfVNQ7opl+nGZ5g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F/A5kuGhJ0+Aiff66U6dbI4FktPNXF8XWv/Yp0bedYMVbb4WWAtAdDGNoszgQre3hlDyJaLEz+gnd0VZdcDMwSMPVlnBN8leUpLmlUCfdtoTb0irK3RkWVBGIn5MmszfO1fmBUxP1V5/XyCp9FIX0Vx+Ew3PIorg07q8DI+zdRE= 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.198]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV0XyvzYQv22; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id B553F40579; Mon, 11 May 2026 15:28:22 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S7; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 03/23] ext4: simplify error handling in ext4_setattr() Date: Mon, 11 May 2026 15:23:23 +0800 Message-ID: <20260511072344.191271-4-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S7 X-Coremail-Antispam: 1UD129KBjvJXoWxZr13JF1kCFW3Zr1UAry5Arb_yoW5XrWUpF 13Ga4qkr48XF1UWr48KFy7Zw1Fg3WIq3y8Zry3K3Z7AFn5JwnFqFy2qa4SgFW5GrWkGw1a qF4UKr9xCFy7Z3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjfUO_MaUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Refactor the error handling in ext4_setattr() for better clarity: - Return directly on ext4_break_layouts() failure. - Propagate ext4_truncate() errors using the existing error variable and jump to the common 'err_out' label. - Propagate posix_acl_chmod() errors also through the error variable, as it theoretically does not return a non-fatal error. With these changes, every error path either returns immediately or jumps to err_out. Consequently, the "if (!error)" condition guarding setattr_copy() and mark_inode_dirty() becomes unreachable for error cases. Remove this redundant check and the unused rc variable can be removed as well. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 35e958f89bd5..b1ef706987c3 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5989,7 +5989,7 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dent= ry *dentry, struct iattr *attr) { struct inode *inode =3D d_inode(dentry); - int error, rc =3D 0; + int error; int orphan =3D 0; const unsigned int ia_valid =3D attr->ia_valid; bool inc_ivers =3D true; @@ -6102,10 +6102,10 @@ int ext4_setattr(struct mnt_idmap *idmap, struct de= ntry *dentry, =20 filemap_invalidate_lock(inode->i_mapping); =20 - rc =3D ext4_break_layouts(inode); - if (rc) { + error =3D ext4_break_layouts(inode); + if (error) { filemap_invalidate_unlock(inode->i_mapping); - goto err_out; + return error; } =20 if (attr->ia_size > oldsize) @@ -6117,15 +6117,19 @@ int ext4_setattr(struct mnt_idmap *idmap, struct de= ntry *dentry, } =20 filemap_invalidate_unlock(inode->i_mapping); + if (error) + goto err_out; } =20 - if (!error) { - if (inc_ivers) - inode_inc_iversion(inode); - setattr_copy(idmap, inode, attr); - mark_inode_dirty(inode); - } + if (inc_ivers) + inode_inc_iversion(inode); + setattr_copy(idmap, inode, attr); + mark_inode_dirty(inode); =20 + if (ia_valid & ATTR_MODE) + error =3D posix_acl_chmod(idmap, dentry, inode->i_mode); + +err_out: /* * If the call to ext4_truncate failed to get a transaction handle at * all, we need to clean up the in-core orphan list manually. @@ -6133,14 +6137,8 @@ int ext4_setattr(struct mnt_idmap *idmap, struct den= try *dentry, if (orphan && inode->i_nlink) ext4_orphan_del(NULL, inode); =20 - if (!error && (ia_valid & ATTR_MODE)) - rc =3D posix_acl_chmod(idmap, dentry, inode->i_mode); - -err_out: - if (error) + if (error) ext4_std_error(inode->i_sb, error); - if (!error) - error =3D rc; return error; } =20 --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 9AA4F386450; Mon, 11 May 2026 07:28:31 +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=1778484515; cv=none; b=iUOsOGhi2EPRabHrBBF+bEUCiqfsHFDSJ1M6SjnstsVaQDQSBHHCdvAqhCkQNL/RwOdDqBKMukhevvuoHFda2vCxzLwgu4i+P0nYf8cojhwz3zs2BiNRPjoclnbbgf+XBMjnAeoVFK6gKvYB0iT4JVDS3UDohCfoCjLTBv2Y7h4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484515; c=relaxed/simple; bh=Wh5+1VdME5OC6sAKzkIpJoS6Iv+FfSiX8t4AbnJ5FgA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rbewpgsMVk87iPpGsHiy7mpwjK2CqdTeSD7X2IxMj60PWjOKnMZGHShC0ZXo60CJIHzzU5+o0yL5kq30IQe/Ff9WkHmssZCIb1d/e9Rf/a71ZMMMihGevMSyr4lTnzH3n5Bt5f0BCdzlt41gQixp+ALH1TU96nGwer+Z8sbMVMc= 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.198]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV1225zYQv2H; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id C79F44057A; Mon, 11 May 2026 15:28:22 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S8; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 04/23] ext4: add iomap address space operations for buffered I/O Date: Mon, 11 May 2026 15:23:24 +0800 Message-ID: <20260511072344.191271-5-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S8 X-Coremail-Antispam: 1UD129KBjvJXoWxXF1DuryDWryrtF4rGryfZwb_yoWrJryxpF Z8Kas5Gr18XF9rua1SqFZrZF4Yka4fJw4jgFW3W3Wa9Fy5G3y7KFW0k3WYkFy5K3y8Ar12 qF4j9rW7WF17CrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Introduce initial support for iomap in the buffered I/O path for regular files on ext4. - Add a new inode state flag EXT4_STATE_BUFFERED_IOMAP to indicate the inode uses iomap instead of buffer_head for buffered I/O - Add helper ext4_inode_buffered_iomap() to check the flag - Add new address space operations ext4_iomap_aops with callbacks that will use generic iomap implementations - Add ext4_iomap_aops to ext4_set_aops() when the flag is set The following callbacks(read_folio(), readahead(), writepages()) are provided as placeholders and will be implemented in later patches. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/ext4.h | 7 +++++++ fs/ext4/inode.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 94283a991e5c..1e27d73d7427 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1972,6 +1972,7 @@ enum { EXT4_STATE_FC_COMMITTING, /* Fast commit ongoing */ EXT4_STATE_FC_FLUSHING_DATA, /* Fast commit flushing data */ EXT4_STATE_ORPHAN_FILE, /* Inode orphaned in orphan file */ + EXT4_STATE_BUFFERED_IOMAP, /* Inode use iomap for buffered IO */ }; =20 #define EXT4_INODE_BIT_FNS(name, field, offset) \ @@ -2040,6 +2041,12 @@ static inline bool ext4_inode_orphan_tracked(struct = inode *inode) !list_empty(&EXT4_I(inode)->i_orphan); } =20 +/* Whether the inode pass through the iomap infrastructure for buffered I/= O */ +static inline bool ext4_inode_buffered_iomap(struct inode *inode) +{ + return ext4_test_inode_state(inode, EXT4_STATE_BUFFERED_IOMAP); +} + /* * Codes for operating systems */ diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index b1ef706987c3..178ac2be37b7 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3908,6 +3908,22 @@ const struct iomap_ops ext4_iomap_report_ops =3D { .iomap_begin =3D ext4_iomap_begin_report, }; =20 +static int ext4_iomap_read_folio(struct file *file, struct folio *folio) +{ + return 0; +} + +static void ext4_iomap_readahead(struct readahead_control *rac) +{ + +} + +static int ext4_iomap_writepages(struct address_space *mapping, + struct writeback_control *wbc) +{ + return 0; +} + /* * For data=3Djournal mode, folio should be marked dirty only when it was * writeably mapped. When that happens, it was already attached to the @@ -3994,6 +4010,20 @@ static const struct address_space_operations ext4_da= _aops =3D { .swap_activate =3D ext4_iomap_swap_activate, }; =20 +static const struct address_space_operations ext4_iomap_aops =3D { + .read_folio =3D ext4_iomap_read_folio, + .readahead =3D ext4_iomap_readahead, + .writepages =3D ext4_iomap_writepages, + .dirty_folio =3D iomap_dirty_folio, + .bmap =3D ext4_bmap, + .invalidate_folio =3D iomap_invalidate_folio, + .release_folio =3D iomap_release_folio, + .migrate_folio =3D filemap_migrate_folio, + .is_partially_uptodate =3D iomap_is_partially_uptodate, + .error_remove_folio =3D generic_error_remove_folio, + .swap_activate =3D ext4_iomap_swap_activate, +}; + static const struct address_space_operations ext4_dax_aops =3D { .writepages =3D ext4_dax_writepages, .dirty_folio =3D noop_dirty_folio, @@ -4015,6 +4045,8 @@ void ext4_set_aops(struct inode *inode) } if (IS_DAX(inode)) inode->i_mapping->a_ops =3D &ext4_dax_aops; + else if (ext4_inode_buffered_iomap(inode)) + inode->i_mapping->a_ops =3D &ext4_iomap_aops; else if (test_opt(inode->i_sb, DELALLOC)) inode->i_mapping->a_ops =3D &ext4_da_aops; else --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 5A503382F14; Mon, 11 May 2026 07:28:33 +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=1778484516; cv=none; b=T1z3hr6knnmjA4SgFOOP0OPPWS+wo7AGUpa2YqkdORovhlvkYdhor0fPcICYtAjFmOtx5eAf1EVYao0oD+rUf3kpAK4DewTVRHjTsbN2G8wIT9JDAASLsUe/i7UcBxaHFeS2xY/j2aDVFxCq61tUsOfw6Rfl59INReC4PUnzaow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484516; c=relaxed/simple; bh=Juu2kp7nK/4rF0XRi2HHzKc4EPubpvMESQotwzub19s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iq42dNS1zrBUX/Xxer4rgEWPruC+pVIaPmDBxdpLVfDhrsOR8bnrPU6g3MFCUJIVcCBjSUBpJ6TPR+sYNLMH3QTZoidEvNAqCEp/qU6caJ+oXfcDjj7pLxcb5HJ7i5v1sVvpciq++PH1To+slla1JlZjZDWxtGEwac+6r+jMd64= 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.198]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV1WtHzYQv2L; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id D89A340573; Mon, 11 May 2026 15:28:22 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S9; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 05/23] ext4: implement buffered read path using iomap Date: Mon, 11 May 2026 15:23:25 +0800 Message-ID: <20260511072344.191271-6-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S9 X-Coremail-Antispam: 1UD129KBjvJXoWxGrW3tr4DXry8Jw1UJF4ruFg_yoW5XF1fpF 90kFy5Gr4UXrnF9F4SqFZrAr1Fkan7Ja1UWryfGwn8WF90krW2gayjgF1Yv3W5t3y7Ar18 XF4jkry8Wr1UArDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Implement the iomap read path for ext4 by introducing a new ext4_iomap_buffered_read_ops instance. This provides the read_folio() and readahead() callbacks for ext4_iomap_aops. The implementation introduces: - ext4_iomap_map_blocks(): Helper function to query extent mappings for a given read range using ext4_map_blocks() and convert the mapping information to iomap type - ext4_iomap_buffered_read_begin(): The iomap_begin callback that maps blocks, validates filesystem state, and populates the iomap. It returns -ERANGE for inline data which is not yet supported. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 178ac2be37b7..6c4d9137b279 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3908,14 +3908,57 @@ const struct iomap_ops ext4_iomap_report_ops =3D { .iomap_begin =3D ext4_iomap_begin_report, }; =20 +static int ext4_iomap_map_blocks(struct inode *inode, loff_t offset, + loff_t length, struct ext4_map_blocks *map) +{ + u8 blkbits =3D inode->i_blkbits; + + if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK) + return -EINVAL; + + /* Calculate the first and last logical blocks respectively. */ + map->m_lblk =3D offset >> blkbits; + map->m_len =3D min_t(loff_t, (offset + length - 1) >> blkbits, + EXT4_MAX_LOGICAL_BLOCK) - map->m_lblk + 1; + + return ext4_map_blocks(NULL, inode, map, 0); +} + +static int ext4_iomap_buffered_read_begin(struct inode *inode, loff_t offs= et, + loff_t length, unsigned int flags, struct iomap *iomap, + struct iomap *srcmap) +{ + struct ext4_map_blocks map; + int ret; + + if (unlikely(ext4_forced_shutdown(inode->i_sb))) + return -EIO; + + /* Inline data support is not yet available. */ + if (WARN_ON_ONCE(ext4_has_inline_data(inode))) + return -ERANGE; + + ret =3D ext4_iomap_map_blocks(inode, offset, length, &map); + if (ret < 0) + return ret; + + ext4_set_iomap(inode, iomap, &map, offset, length, flags); + return 0; +} + +const struct iomap_ops ext4_iomap_buffered_read_ops =3D { + .iomap_begin =3D ext4_iomap_buffered_read_begin, +}; + static int ext4_iomap_read_folio(struct file *file, struct folio *folio) { + iomap_bio_read_folio(folio, &ext4_iomap_buffered_read_ops); return 0; } =20 static void ext4_iomap_readahead(struct readahead_control *rac) { - + iomap_bio_readahead(rac, &ext4_iomap_buffered_read_ops); } =20 static int ext4_iomap_writepages(struct address_space *mapping, --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 5382C3859F3; Mon, 11 May 2026 07:28:31 +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=1778484514; cv=none; b=fpznGLTfMv0kjCenaIKvhS4B3WfLgyUzwLZ5o014SeefGymBmf5rUd8S9szwBl/Q5G8BOB707LY9Uy9iKCI3pNWyVc841SewPQPT1kHH5WhadrDH421taSXXQkfU8BH5AJHICEZS13iyL4quwgZvVUMRL0eVSiRN44DnLr2euEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484514; c=relaxed/simple; bh=/eHJMpsNuAXg57jXYSG9wTnSZHNzT6OePUgv7hxBe7Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B1LWxxNQL9oRfb9xtsFIEt4FQLPrA/eF1M4ksmdFUgiKa++AToBM2LW8Cl0APDvQvPHBHf4I2uKnSKjypDWEVJc4wdKEmz8tKSg0k0Pp7Nm5cjzj09jDYdRADF2vcJGJgH8+eQ3Bx1nCTQ4jENp848qXXpRdkDo0DeZcoAH0f3Y= 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.198]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV23j9zYQv2V; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id EBC4840574; Mon, 11 May 2026 15:28:22 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S10; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 06/23] ext4: pass out extent seq counter when mapping da blocks Date: Mon, 11 May 2026 15:23:26 +0800 Message-ID: <20260511072344.191271-7-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S10 X-Coremail-Antispam: 1UD129KBjvJXoW7tF1ftFWDJr48AF4xKw1kuFg_yoW8CrWxp3 9YkF1rGw1xZw1q9ay0q3W7ZFyrKa15ArW7GrWfXw1j9a4DGFySqF4jkF12yFykKr4xXr1F vF40kryUC3ySkFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The iomap buffered write path does not hold any locks between querying inode extent mapping information and performing buffered writes. It relies on the sequence counter saved in the inode to detect stale mappings. Commit 07c440e8da8f ("ext4: pass out extent seq counter when mapping blocks") added the m_seq field to ext4_map_blocks to pass out extent sequence numbers, but it missed two callsites within ext4_da_map_blocks(). These callsites are on the delayed allocation path, which is also used in the iomap buffered write path. Pass out the sequence counter to ensure stale mappings can be detected. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 6c4d9137b279..39577a6b65b9 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1929,7 +1929,7 @@ static int ext4_da_map_blocks(struct inode *inode, st= ruct ext4_map_blocks *map) ext4_check_map_extents_env(inode); =20 /* Lookup extent status tree firstly */ - if (ext4_es_lookup_extent(inode, map->m_lblk, NULL, &es, NULL)) { + if (ext4_es_lookup_extent(inode, map->m_lblk, NULL, &es, &map->m_seq)) { map->m_len =3D min_t(unsigned int, map->m_len, es.es_len - (map->m_lblk - es.es_lblk)); =20 @@ -1982,7 +1982,7 @@ static int ext4_da_map_blocks(struct inode *inode, st= ruct ext4_map_blocks *map) * is held in write mode, before inserting a new da entry in * the extent status tree. */ - if (ext4_es_lookup_extent(inode, map->m_lblk, NULL, &es, NULL)) { + if (ext4_es_lookup_extent(inode, map->m_lblk, NULL, &es, &map->m_seq)) { map->m_len =3D min_t(unsigned int, map->m_len, es.es_len - (map->m_lblk - es.es_lblk)); =20 --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 98704383C6F; Mon, 11 May 2026 07:28:36 +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=1778484519; cv=none; b=jMkLZ2ozbUWYrdsluivzIqIU8Sz9xWqGN30FvNG7sPrrpEFi2uMsEiiUE9z+MNRCkN04bZoEq1G2OisvGmnE7oynbsAjMdd6cW3HfMXWh5HLmmCw6ErG1+ZhPkqkZOYIxEie16Zyo/gRlscnmTvk31Y+6jQ8F8a9lvAjLxGXQwg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484519; c=relaxed/simple; bh=K5R16M3oqschNp9djqgRbio2WZjcMBSGBDr/MmrzL8Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gm0WP2QbIdldsGpfGZ3fnshkQbo20myziAiP/QOiif6Ik1VZ/RI997/NzUr6jnfHNMPDTPUua7ZYN4TMk27d4EFgRab8JjXZcdpP6AOnM0Sq1D4YS4pOW2NKH1oqpVA8HpYchoC8yC9DaUCyuwRJRJfpMMJG9ZAyHwhXCT0My0c= 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.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV2T9czYQv2f; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 061624056D; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S11; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 07/23] ext4: do not use data=ordered mode for inodes using buffered iomap path Date: Mon, 11 May 2026 15:23:27 +0800 Message-ID: <20260511072344.191271-8-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S11 X-Coremail-Antispam: 1UD129KBjvJXoWxWFWkuw4DCF4fJw1rGrWUtwb_yoW5ArW5pF W3K3s8J3s5uasFkF4kur4Iqr1Fv3y5Jr4UXFy3KrsxuayDJa1IyFy3tF92ya45trs3G3WI qF48ArW8WFs0yrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The data=3Dordered mode introduces two fundamental conflicts with the iomap buffered write path, leading to potential deadlocks. 1) Lock ordering conflict In the iomap writeback path, each folio is processed sequentially: the folio lock is acquired first, followed by starting a transaction to create block mappings. In data=3Dordered mode, writeback triggered by the journal commit process may attempt to acquire a folio lock that is already held by iomap. Meanwhile, iomap, under that same folio lock, may start a new transaction and wait for the currently committing transaction to finish, resulting in a deadlock. 2) Partial folio submission not supported When block size is smaller than folio size, a folio may contain both mapped and unmapped blocks. In data=3Dordered mode, if the journal waits for such a folio to be written back while the regular writeback process has already started committing it (with the writeback flag set), mapping the remaining unmapped blocks can deadlock. This is because the writeback flag is cleared only after the entire folio is processed and committed. To support data=3Dordered mode, the iomap core would need two invasive changes: - Acquire the transaction handle before locking any folio for writeback. - Support partial folio submission. Both changes are complicated and risk performance regressions. Therefore, we must avoid using data=3Dordered mode when converting to the iomap path. Currently, data=3Dordered mode is used in three scenarios: - Append write - Post-EOF partial block truncate-up followed by append write - Online defragmentation We can address the first two without data=3Dordered mode: - For append write: always allocate unwritten blocks (i.e. always enable dioread_nolock), preserving the behavior of current extent-type inodes. - For post-EOF truncate-up + append write: postpone updating i_disksize until after the zeroed partial block has been written back. Online defragmentation does not yet support iomap; this can be resolved separately in the future. Signed-off-by: Zhang Yi --- fs/ext4/ext4_jbd2.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ext4/ext4_jbd2.h b/fs/ext4/ext4_jbd2.h index 63d17c5201b5..26999f173870 100644 --- a/fs/ext4/ext4_jbd2.h +++ b/fs/ext4/ext4_jbd2.h @@ -383,7 +383,12 @@ static inline int ext4_should_journal_data(struct inod= e *inode) =20 static inline int ext4_should_order_data(struct inode *inode) { - return ext4_inode_journal_mode(inode) & EXT4_INODE_ORDERED_DATA_MODE; + /* + * inodes using the iomap buffered I/O path do not use the + * data=3Dordered mode. + */ + return !ext4_inode_buffered_iomap(inode) && + (ext4_inode_journal_mode(inode) & EXT4_INODE_ORDERED_DATA_MODE); } =20 static inline int ext4_should_writeback_data(struct inode *inode) --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 7C0B638B158; Mon, 11 May 2026 07:28:36 +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=1778484519; cv=none; b=iZqXqs0h+ovtRVlJnG7kBCg4d8NzcW2gzaNCyciaOGotP2GvccESOfEyN/vF4gQgC1cmLqiQnkUSQH6RI1o0kHZpFpJNfYu60vf5j/Zx6obSqHSKbBm41zupqB+f8Uj6zcm0/oR0eBJhmUBEgts6c1yNEZn4I1P8DhcBT5L9l8s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484519; c=relaxed/simple; bh=UUlKzPEQV89T3YdDa37Y62vi5cH3XOY9vTx+YpC8+Ws=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Jer1UawxEyjn0qtGd2vOZcQu55HEQ0j1dIfWVcn6fRoyToT7iEZwvSYoMkw3DsD9bzjNxYaWQc1txN7/ArDY4ToAaZXsZRkByjypT/EFdnpvcbX8YtL3FNDAgBtGaCQW/P+69nXnrU3YJf8CTN+A+S3GUa2i5gOF2teY6/eOp1g= 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.198]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV3K6pzYQv2N; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 204A640573; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S12; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 08/23] ext4: implement buffered write path using iomap Date: Mon, 11 May 2026 15:23:28 +0800 Message-ID: <20260511072344.191271-9-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S12 X-Coremail-Antispam: 1UD129KBjvJXoWfGFyDXFy5JF1fXF1UCw4rKrg_yoWktFWrpF Z0kry5Gr47Xr97uF4fKF47Zr1F93WxtrW7CrW3Wrn8Xr90yrWIga18KFyayF15trWxCr4j qF4jkry8Ww4UCrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Introduce two new iomap_ops instances for ext4 buffered writes: - ext4_iomap_buffered_da_write_ops: for delayed allocation mode, using ext4_da_map_blocks() to map delalloc extents. - ext4_iomap_buffered_write_ops: for non-delayed allocation mode, using ext4_iomap_get_blocks() to directly allocate blocks. Also add ext4_iomap_valid() for the iomap infrastructure to check extent validity. Key changes and considerations: - Unwritten extents for new blocks (dioread_nolock always on) Since data=3Dordered mode is not used to prevent stale data exposure in the non-delayed allocation path, new blocks are always allocated as unwritten extents. - Short write and write failure handling a. Delalloc path: On short write or failure, the stale delalloc range must be dropped and its space reservation released. Otherwise, a clean folio may cover leftover delalloc extents, causing inaccurate space reservation accounting. b. Non-delalloc path: No cleanup of allocated blocks is needed on short write. - Lock ordering reversal The folio lock and transaction start ordering is reversed compared to the buffer_head buffered write path. To handle this, the journal handle must be stopped in iomap_begin() callbacks. The lock ordering documentation in super.c has been updated accordingly. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/ext4.h | 4 ++ fs/ext4/file.c | 20 +++++- fs/ext4/inode.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++- fs/ext4/super.c | 10 ++- 4 files changed, 192 insertions(+), 7 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 1e27d73d7427..4832e7f7db82 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -3057,6 +3057,7 @@ int ext4_walk_page_buffers(handle_t *handle, int do_journal_get_write_access(handle_t *handle, struct inode *inode, struct buffer_head *bh); void ext4_set_inode_mapping_order(struct inode *inode); +int ext4_nonda_switch(struct super_block *sb); #define FALL_BACK_TO_NONDELALLOC 1 #define CONVERT_INLINE_DATA 2 =20 @@ -3926,6 +3927,9 @@ static inline void ext4_clear_io_unwritten_flag(ext4_= io_end_t *io_end) =20 extern const struct iomap_ops ext4_iomap_ops; extern const struct iomap_ops ext4_iomap_report_ops; +extern const struct iomap_ops ext4_iomap_buffered_write_ops; +extern const struct iomap_ops ext4_iomap_buffered_da_write_ops; +extern const struct iomap_write_ops ext4_iomap_write_ops; =20 static inline int ext4_buffer_uptodate(struct buffer_head *bh) { diff --git a/fs/ext4/file.c b/fs/ext4/file.c index eb1a323962b1..7f9bfbbc4a4e 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -299,6 +299,21 @@ static ssize_t ext4_write_checks(struct kiocb *iocb, s= truct iov_iter *from) return count; } =20 +static ssize_t ext4_iomap_buffered_write(struct kiocb *iocb, + struct iov_iter *from) +{ + struct inode *inode =3D file_inode(iocb->ki_filp); + const struct iomap_ops *iomap_ops; + + if (test_opt(inode->i_sb, DELALLOC) && !ext4_nonda_switch(inode->i_sb)) + iomap_ops =3D &ext4_iomap_buffered_da_write_ops; + else + iomap_ops =3D &ext4_iomap_buffered_write_ops; + + return iomap_file_buffered_write(iocb, from, iomap_ops, + &ext4_iomap_write_ops, NULL); +} + static ssize_t ext4_buffered_write_iter(struct kiocb *iocb, struct iov_iter *from) { @@ -313,7 +328,10 @@ static ssize_t ext4_buffered_write_iter(struct kiocb *= iocb, if (ret <=3D 0) goto out; =20 - ret =3D generic_perform_write(iocb, from); + if (ext4_inode_buffered_iomap(inode)) + ret =3D ext4_iomap_buffered_write(iocb, from); + else + ret =3D generic_perform_write(iocb, from); =20 out: inode_unlock(inode); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 39577a6b65b9..1ae7d3f4a1c8 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3097,7 +3097,7 @@ static int ext4_dax_writepages(struct address_space *= mapping, return ret; } =20 -static int ext4_nonda_switch(struct super_block *sb) +int ext4_nonda_switch(struct super_block *sb) { s64 free_clusters, dirty_clusters; struct ext4_sb_info *sbi =3D EXT4_SB(sb); @@ -3467,6 +3467,15 @@ static bool ext4_inode_datasync_dirty(struct inode *= inode) return inode_state_read_once(inode) & I_DIRTY_DATASYNC; } =20 +static bool ext4_iomap_valid(struct inode *inode, const struct iomap *ioma= p) +{ + return iomap->validity_cookie =3D=3D READ_ONCE(EXT4_I(inode)->i_es_seq); +} + +const struct iomap_write_ops ext4_iomap_write_ops =3D { + .iomap_valid =3D ext4_iomap_valid, +}; + static void ext4_set_iomap(struct inode *inode, struct iomap *iomap, struct ext4_map_blocks *map, loff_t offset, loff_t length, unsigned int flags) @@ -3501,6 +3510,8 @@ static void ext4_set_iomap(struct inode *inode, struc= t iomap *iomap, !ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) iomap->flags |=3D IOMAP_F_MERGED; =20 + iomap->validity_cookie =3D map->m_seq; + /* * Flags passed to ext4_map_blocks() for direct I/O writes can result * in m_flags having both EXT4_MAP_MAPPED and EXT4_MAP_UNWRITTEN bits @@ -3908,8 +3919,12 @@ const struct iomap_ops ext4_iomap_report_ops =3D { .iomap_begin =3D ext4_iomap_begin_report, }; =20 +/* Map blocks */ +typedef int (ext4_get_blocks_t)(struct inode *, struct ext4_map_blocks *); + static int ext4_iomap_map_blocks(struct inode *inode, loff_t offset, - loff_t length, struct ext4_map_blocks *map) + loff_t length, ext4_get_blocks_t get_blocks, + struct ext4_map_blocks *map) { u8 blkbits =3D inode->i_blkbits; =20 @@ -3921,6 +3936,9 @@ static int ext4_iomap_map_blocks(struct inode *inode,= loff_t offset, map->m_len =3D min_t(loff_t, (offset + length - 1) >> blkbits, EXT4_MAX_LOGICAL_BLOCK) - map->m_lblk + 1; =20 + if (get_blocks) + return get_blocks(inode, map); + return ext4_map_blocks(NULL, inode, map, 0); } =20 @@ -3938,7 +3956,7 @@ static int ext4_iomap_buffered_read_begin(struct inod= e *inode, loff_t offset, if (WARN_ON_ONCE(ext4_has_inline_data(inode))) return -ERANGE; =20 - ret =3D ext4_iomap_map_blocks(inode, offset, length, &map); + ret =3D ext4_iomap_map_blocks(inode, offset, length, NULL, &map); if (ret < 0) return ret; =20 @@ -3946,6 +3964,147 @@ static int ext4_iomap_buffered_read_begin(struct in= ode *inode, loff_t offset, return 0; } =20 +static int ext4_iomap_get_blocks(struct inode *inode, + struct ext4_map_blocks *map) +{ + loff_t i_size =3D i_size_read(inode); + handle_t *handle; + int ret; + + /* + * Check if the blocks have already been allocated, this could + * avoid initiating a new journal transaction and return the + * mapping information directly. + */ + if ((map->m_lblk + map->m_len) <=3D + round_up(i_size, i_blocksize(inode)) >> inode->i_blkbits) { + ret =3D ext4_map_blocks(NULL, inode, map, 0); + if (ret < 0) + return ret; + if (map->m_flags & (EXT4_MAP_MAPPED | EXT4_MAP_UNWRITTEN | + EXT4_MAP_DELAYED)) + return 0; + } + + handle =3D ext4_journal_start(inode, EXT4_HT_MAP_BLOCKS, + ext4_chunk_trans_blocks(inode, map->m_len)); + if (IS_ERR(handle)) + return PTR_ERR(handle); + + ret =3D ext4_map_blocks(handle, inode, map, + EXT4_GET_BLOCKS_CREATE_UNWRIT_EXT); + /* + * Stop handle here following the lock ordering of the folio lock + * and the transaction start. + */ + ext4_journal_stop(handle); + + return ret; +} + +static int ext4_iomap_buffered_do_write_begin(struct inode *inode, + loff_t offset, loff_t length, unsigned int flags, + struct iomap *iomap, struct iomap *srcmap, bool delalloc) +{ + int ret, retries =3D 0; + struct ext4_map_blocks map; + ext4_get_blocks_t *get_blocks; + + ret =3D ext4_emergency_state(inode->i_sb); + if (unlikely(ret)) + return ret; + + /* Inline data and non-extent are not supported. */ + if (WARN_ON_ONCE(ext4_has_inline_data(inode))) + return -ERANGE; + if (WARN_ON_ONCE(!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) + return -EINVAL; + if (WARN_ON_ONCE(!(flags & IOMAP_WRITE))) + return -EINVAL; + + if (delalloc) + get_blocks =3D ext4_da_map_blocks; + else + get_blocks =3D ext4_iomap_get_blocks; +retry: + ret =3D ext4_iomap_map_blocks(inode, offset, length, get_blocks, &map); + if (ret =3D=3D -ENOSPC && ext4_should_retry_alloc(inode->i_sb, &retries)) + goto retry; + if (ret < 0) + return ret; + + ext4_set_iomap(inode, iomap, &map, offset, length, flags); + return 0; +} + +static int ext4_iomap_buffered_write_begin(struct inode *inode, + loff_t offset, loff_t length, unsigned int flags, + struct iomap *iomap, struct iomap *srcmap) +{ + return ext4_iomap_buffered_do_write_begin(inode, offset, length, flags, + iomap, srcmap, false); +} + +static int ext4_iomap_buffered_da_write_begin(struct inode *inode, + loff_t offset, loff_t length, unsigned int flags, + struct iomap *iomap, struct iomap *srcmap) +{ + return ext4_iomap_buffered_do_write_begin(inode, offset, length, flags, + iomap, srcmap, true); +} + +/* + * On write failure, drop the stale delayed allocation range and release + * its reserved space for both start and end blocks. Otherwise, we may + * leave a range of delayed extents covered by a clean folio, which can + * result in inaccurate space reservation accounting. + */ +static void ext4_iomap_punch_delalloc(struct inode *inode, loff_t offset, + loff_t length, struct iomap *iomap) +{ + down_write(&EXT4_I(inode)->i_data_sem); + ext4_es_remove_extent(inode, offset >> inode->i_blkbits, + DIV_ROUND_UP_ULL(length, EXT4_BLOCK_SIZE(inode->i_sb))); + up_write(&EXT4_I(inode)->i_data_sem); +} + +static int ext4_iomap_buffered_da_write_end(struct inode *inode, loff_t of= fset, + loff_t length, ssize_t written, + unsigned int flags, + struct iomap *iomap) +{ + loff_t start_byte, end_byte; + + /* If we didn't reserve the blocks, we're not allowed to punch them. */ + if (iomap->type !=3D IOMAP_DELALLOC || !(iomap->flags & IOMAP_F_NEW)) + return 0; + + /* Nothing to do if we've written the entire delalloc extent */ + start_byte =3D iomap_last_written_block(inode, offset, written); + end_byte =3D round_up(offset + length, i_blocksize(inode)); + if (start_byte >=3D end_byte) + return 0; + + filemap_invalidate_lock(inode->i_mapping); + iomap_write_delalloc_release(inode, start_byte, end_byte, flags, + iomap, ext4_iomap_punch_delalloc); + filemap_invalidate_unlock(inode->i_mapping); + return 0; +} + +/* + * Since we always allocate unwritten extents, there is no need for + * iomap_end to clean up allocated blocks on a short write. + */ +const struct iomap_ops ext4_iomap_buffered_write_ops =3D { + .iomap_begin =3D ext4_iomap_buffered_write_begin, +}; + +const struct iomap_ops ext4_iomap_buffered_da_write_ops =3D { + .iomap_begin =3D ext4_iomap_buffered_da_write_begin, + .iomap_end =3D ext4_iomap_buffered_da_write_end, +}; + const struct iomap_ops ext4_iomap_buffered_read_ops =3D { .iomap_begin =3D ext4_iomap_buffered_read_begin, }; diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 6a77db4d3124..9bc294b769db 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -104,9 +104,13 @@ static const struct fs_parameter_spec ext4_param_specs= []; * -> page lock -> i_data_sem (rw) * * buffered write path: - * sb_start_write -> i_mutex -> mmap_lock - * sb_start_write -> i_mutex -> transaction start -> page lock -> - * i_data_sem (rw) + * sb_start_write -> i_rwsem (w) -> mmap_lock + * - buffer_head path: + * sb_start_write -> i_rwsem (w) -> transaction start -> folio lock -> + * i_data_sem (rw) + * - iomap path: + * sb_start_write -> i_rwsem (w) -> transaction start -> i_data_sem (rw) + * sb_start_write -> i_rwsem (w) -> folio lock (not under an active hand= le) * * truncate: * sb_start_write -> i_mutex -> invalidate_lock (w) -> i_mmap_rwsem (w) -> --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 4734C3815CF; Mon, 11 May 2026 07:28:27 +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=1778484510; cv=none; b=f2ECEGzO4zjG5Fipau/NWti3X1l9K60szUGBLGbvXK+jXdoCl+NsvDao68bBHberfKYOyp85NBFQrZHltanZY1REmWJNbJe8YkKBJxpR8wxVUpdnwuN6KWDUBcPK6l+4Sn6U+l45ZNq1M170oOx6mSplK/a2vPmwSkUPZk8GTYs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484510; c=relaxed/simple; bh=Xj1sKocGpz6KmqLc67YM9o6EWYK7tQFHy9OP+TKDDIg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iXLYE/Y4/V6gPOScYkn73ce83U8PT+zTX4bvvFxHXLB5gcgcYgokc2fFRGopnbQH6G4ae/OOfPpJ4yPNI+xrkBAAmFLZ2AuHGp2EveAcXjcpdRBblYg4LuqRVo1CEzSUQ8bAaUOKj0UmQ92OLgQvEiOs4DzsLQuOTEpxFPZFV2Y= 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.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX44vl0zKHMdm; Mon, 11 May 2026 15:27:32 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 348484056B; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S13; Mon, 11 May 2026 15:28:22 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 09/23] ext4: implement writeback path using iomap Date: Mon, 11 May 2026 15:23:29 +0800 Message-ID: <20260511072344.191271-10-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S13 X-Coremail-Antispam: 1UD129KBjvAXoWfGFy3KFyDXFWrAFW8KF4rKrg_yoW8ArW8Ko Waqa13Xr48Jry5tayrGr1ftFyUuan7Gw4rJr45ZrsFva43Ja4Yvw4fKw43W3W7Xw4FkFWS yrWxJa1rGr48JF1rn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUOV7AC8VAFwI0_Wr0E3s1l1xkIjI8I6I8E6xAIw20EY4v20xva j40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l82xGYIkIc2x26280x7IE14v26r126s0DM28Irc Ia0xkI8VCY1x0267AKxVW5JVCq3wA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l 84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4UJV WxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE 3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2I x0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8 JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2 ka0xkIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Y z7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zV AF1VAY17CE14v26r4a6rW5MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_JFI_Gr1l IxAIcVC0I7IYx2IY6xkF7I0E14v26r4UJVWxJr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r 1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJbIY CTnIWIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Add the iomap writeback path for ext4 buffered I/O. This introduces: - ext4_iomap_writepages(): the main writeback entry point. - ext4_writeback_ops: a new iomap_writeback_ops instance to handle block mapping and I/O submission. - A new end I/O worker for converting unwritten extents, updating file size, and handling DATA_ERR_ABORT after I/O completion. Core implementation details: - ->writeback_range() callback Calls ext4_iomap_map_writeback_range() to query the longest range of existing mapped extents. For performance, when a block range is not yet allocated, it allocates based on the writeback length and delalloc extent length, rather than allocating for a single folio at a time. The folio is then added to an iomap_ioend instance. - ->writeback_submit() callback Registers ext4_iomap_end_bio() as the end bio callback. This callback schedules a worker to handle: - Unwritten extent conversion. - i_disksize update after data is written back. - Journal abort on writeback I/O failure. Key changes and considerations: - Append write and unwritten extents Since data=3Dordered mode is not used to prevent stale data exposure during append writebacks, new blocks are always allocated as unwritten extents (i.e. always enable dioread_nolock), and i_disksize update is postponed until I/O completion. Additionally, the deadlock that the reserve handle was expected to resolve does not occur anymore. Therefore, the end I/O worker can start a normal journal handle instead of a reserve handle when converting unwritten extents. - Lock ordering The ->writeback_range() callback runs under the folio lock, requiring the journal handle to be started under that same lock. This reverses the order compared to the buffer_head writeback path. The lock ordering documentation in super.c has been updated accordingly. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/ext4.h | 4 + fs/ext4/inode.c | 208 +++++++++++++++++++++++++++++++++++++++++- fs/ext4/page-io.c | 126 +++++++++++++++++++++++++ fs/ext4/super.c | 7 +- fs/iomap/ioend.c | 3 +- include/linux/iomap.h | 1 + 6 files changed, 346 insertions(+), 3 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 4832e7f7db82..078feda47e36 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1173,6 +1173,8 @@ struct ext4_inode_info { */ struct list_head i_rsv_conversion_list; struct work_struct i_rsv_conversion_work; + struct list_head i_iomap_ioend_list; + struct work_struct i_iomap_ioend_work; =20 /* * Transactions that contain inode's metadata needed to complete @@ -3870,6 +3872,8 @@ int ext4_bio_write_folio(struct ext4_io_submit *io, s= truct folio *page, size_t len); extern struct ext4_io_end_vec *ext4_alloc_io_end_vec(ext4_io_end_t *io_end= ); extern struct ext4_io_end_vec *ext4_last_io_end_vec(ext4_io_end_t *io_end); +extern void ext4_iomap_end_io(struct work_struct *work); +extern void ext4_iomap_end_bio(struct bio *bio); =20 /* mmp.c */ extern int ext4_multi_mount_protect(struct super_block *, ext4_fsblk_t); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 1ae7d3f4a1c8..a80195bd6f20 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -44,6 +44,7 @@ #include =20 #include "ext4_jbd2.h" +#include "ext4_extents.h" #include "xattr.h" #include "acl.h" #include "truncate.h" @@ -4120,10 +4121,215 @@ static void ext4_iomap_readahead(struct readahead_= control *rac) iomap_bio_readahead(rac, &ext4_iomap_buffered_read_ops); } =20 +static int ext4_iomap_map_one_extent(struct inode *inode, + struct ext4_map_blocks *map) +{ + struct extent_status es; + handle_t *handle =3D NULL; + int credits, map_flags; + int retval; + + credits =3D ext4_chunk_trans_blocks(inode, map->m_len); + handle =3D ext4_journal_start(inode, EXT4_HT_WRITE_PAGE, credits); + if (IS_ERR(handle)) + return PTR_ERR(handle); + + map->m_flags =3D 0; + /* + * It is necessary to look up extent and map blocks under i_data_sem + * in write mode, otherwise, the delalloc extent may become stale + * during concurrent truncate operations. + */ + ext4_fc_track_inode(handle, inode); + down_write(&EXT4_I(inode)->i_data_sem); + if (ext4_es_lookup_extent(inode, map->m_lblk, NULL, &es, &map->m_seq)) { + retval =3D es.es_len - (map->m_lblk - es.es_lblk); + map->m_len =3D min_t(unsigned int, retval, map->m_len); + + if (ext4_es_is_delayed(&es)) { + map->m_flags |=3D EXT4_MAP_DELAYED; + trace_ext4_da_write_pages_extent(inode, map); + /* + * Call ext4_map_create_blocks() to allocate any + * delayed allocation blocks. It is possible that + * we're going to need more metadata blocks, however + * we must not fail because we're in writeback and + * there is nothing we can do so it might result in + * data loss. So use reserved blocks to allocate + * metadata if possible. + */ + map_flags =3D EXT4_GET_BLOCKS_CREATE_UNWRIT_EXT | + EXT4_GET_BLOCKS_METADATA_NOFAIL | + EXT4_EX_NOCACHE; + + retval =3D ext4_map_create_blocks(handle, inode, map, + map_flags); + if (retval > 0) + ext4_fc_track_range(handle, inode, map->m_lblk, + map->m_lblk + map->m_len - 1); + goto out; + } else if (unlikely(ext4_es_is_hole(&es))) + goto out; + + /* Found written or unwritten extent. */ + map->m_pblk =3D ext4_es_pblock(&es) + map->m_lblk - es.es_lblk; + map->m_flags =3D ext4_es_is_written(&es) ? + EXT4_MAP_MAPPED : EXT4_MAP_UNWRITTEN; + goto out; + } + + retval =3D ext4_map_query_blocks(handle, inode, map, EXT4_EX_NOCACHE); +out: + up_write(&EXT4_I(inode)->i_data_sem); + ext4_journal_stop(handle); + return retval < 0 ? retval : 0; +} + +static int ext4_iomap_map_writeback_range(struct iomap_writepage_ctx *wpc, + loff_t offset, unsigned int dirty_len) +{ + struct inode *inode =3D wpc->inode; + struct super_block *sb =3D inode->i_sb; + struct journal_s *journal =3D EXT4_SB(sb)->s_journal; + struct ext4_map_blocks map; + unsigned int blkbits =3D inode->i_blkbits; + unsigned int index =3D offset >> blkbits; + unsigned int blk_end, blk_len; + int ret; + + ret =3D ext4_emergency_state(sb); + if (unlikely(ret)) + return ret; + + /* Check validity of the cached writeback mapping. */ + if (offset >=3D wpc->iomap.offset && + offset < wpc->iomap.offset + wpc->iomap.length && + ext4_iomap_valid(inode, &wpc->iomap)) + return 0; + + blk_len =3D dirty_len >> blkbits; + blk_end =3D min_t(unsigned int, (wpc->wbc->range_end >> blkbits), + (UINT_MAX - 1)); + if (blk_end > index + blk_len) + blk_len =3D blk_end - index + 1; + +retry: + map.m_lblk =3D index; + map.m_len =3D min_t(unsigned int, MAX_WRITEPAGES_EXTENT_LEN, blk_len); + ret =3D ext4_map_blocks(NULL, inode, &map, + EXT4_GET_BLOCKS_IO_SUBMIT | EXT4_EX_NOCACHE); + if (ret < 0) + return ret; + + /* + * The map is not a delalloc extent, it must either be a hole + * or an extent which have already been allocated. + */ + if (!(map.m_flags & EXT4_MAP_DELAYED)) + goto out; + + /* Map one delalloc extent. */ + ret =3D ext4_iomap_map_one_extent(inode, &map); + if (ret < 0) { + if (ext4_emergency_state(sb)) + return ret; + + /* + * Retry transient ENOSPC errors, if + * ext4_count_free_blocks() is non-zero, a commit + * should free up blocks. + */ + if (ret =3D=3D -ENOSPC && journal && ext4_count_free_clusters(sb)) { + jbd2_journal_force_commit_nested(journal); + goto retry; + } + + ext4_msg(sb, KERN_CRIT, + "Delayed block allocation failed for inode %llu at logical offset %llu= with max blocks %u with error %d", + inode->i_ino, (unsigned long long)map.m_lblk, + (unsigned int)map.m_len, -ret); + ext4_msg(sb, KERN_CRIT, + "This should not happen!! Data will be lost\n"); + if (ret =3D=3D -ENOSPC) + ext4_print_free_blocks(inode); + return ret; + } +out: + ext4_set_iomap(inode, &wpc->iomap, &map, offset, dirty_len, 0); + return 0; +} + +static void ext4_iomap_discard_folio(struct folio *folio, loff_t pos) +{ + struct inode *inode =3D folio->mapping->host; + loff_t length =3D folio_pos(folio) + folio_size(folio) - pos; + + ext4_iomap_punch_delalloc(inode, pos, length, NULL); +} + +static ssize_t ext4_iomap_writeback_range(struct iomap_writepage_ctx *wpc, + struct folio *folio, u64 offset, + unsigned int len, u64 end_pos) +{ + ssize_t ret; + + ret =3D ext4_iomap_map_writeback_range(wpc, offset, len); + if (!ret) + ret =3D iomap_add_to_ioend(wpc, folio, offset, end_pos, len); + if (ret < 0) + ext4_iomap_discard_folio(folio, offset); + return ret; +} + +static int ext4_iomap_writeback_submit(struct iomap_writepage_ctx *wpc, + int error) +{ + struct iomap_ioend *ioend =3D wpc->wb_ctx; + struct ext4_inode_info *ei =3D EXT4_I(ioend->io_inode); + + /* + * After I/O completion, a worker needs to be scheduled when: + * 1) Unwritten extents require conversion. + * 2) The file size needs to be extended. + * 3) The journal needs to be aborted due to an I/O error. + */ + if ((ioend->io_flags & IOMAP_IOEND_UNWRITTEN) || + (ioend->io_offset + ioend->io_size > READ_ONCE(ei->i_disksize)) || + test_opt(ioend->io_inode->i_sb, DATA_ERR_ABORT)) + ioend->io_bio.bi_end_io =3D ext4_iomap_end_bio; + + return iomap_ioend_writeback_submit(wpc, error); +} + +static const struct iomap_writeback_ops ext4_writeback_ops =3D { + .writeback_range =3D ext4_iomap_writeback_range, + .writeback_submit =3D ext4_iomap_writeback_submit, +}; + static int ext4_iomap_writepages(struct address_space *mapping, struct writeback_control *wbc) { - return 0; + struct inode *inode =3D mapping->host; + struct super_block *sb =3D inode->i_sb; + long nr =3D wbc->nr_to_write; + int alloc_ctx, ret; + struct iomap_writepage_ctx wpc =3D { + .inode =3D inode, + .wbc =3D wbc, + .ops =3D &ext4_writeback_ops, + }; + + ret =3D ext4_emergency_state(sb); + if (unlikely(ret)) + return ret; + + alloc_ctx =3D ext4_writepages_down_read(sb); + trace_ext4_writepages(inode, wbc); + ret =3D iomap_writepages(&wpc); + trace_ext4_writepages_result(inode, wbc, ret, nr - wbc->nr_to_write); + ext4_writepages_up_read(sb, alloc_ctx); + + return ret; } =20 /* diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c index dc82e7b57e75..3050c887329f 100644 --- a/fs/ext4/page-io.c +++ b/fs/ext4/page-io.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -611,3 +612,128 @@ int ext4_bio_write_folio(struct ext4_io_submit *io, s= truct folio *folio, =20 return 0; } + +static int ext4_iomap_wb_update_disksize(handle_t *handle, struct inode *i= node, + loff_t end) +{ + loff_t new_disksize =3D end; + struct ext4_inode_info *ei =3D EXT4_I(inode); + int ret; + + if (new_disksize <=3D READ_ONCE(ei->i_disksize)) + return 0; + + /* + * Update on-disk size after IO is completed. Races with truncate + * are avoided by checking i_size under i_data_sem. + */ + down_write(&ei->i_data_sem); + new_disksize =3D min(new_disksize, i_size_read(inode)); + if (new_disksize > ei->i_disksize) + ei->i_disksize =3D new_disksize; + up_write(&ei->i_data_sem); + ret =3D ext4_mark_inode_dirty(handle, inode); + if (ret) + EXT4_ERROR_INODE_ERR(inode, -ret, "Failed to mark inode dirty"); + + return ret; +} + +static void ext4_iomap_finish_ioend(struct iomap_ioend *ioend) +{ + struct inode *inode =3D ioend->io_inode; + struct super_block *sb =3D inode->i_sb; + loff_t pos =3D ioend->io_offset; + size_t size =3D ioend->io_size; + handle_t *handle; + int credits; + int ret, err; + + ret =3D blk_status_to_errno(ioend->io_bio.bi_status); + if (unlikely(ret)) { + if (test_opt(sb, DATA_ERR_ABORT) && !ext4_emergency_state(sb)) + jbd2_journal_abort(EXT4_SB(sb)->s_journal, ret); + goto out; + } + + /* We may need to convert one extent and dirty the inode. */ + credits =3D ext4_chunk_trans_blocks(inode, + EXT4_MAX_BLOCKS(size, pos, inode->i_blkbits)); + handle =3D ext4_journal_start(inode, EXT4_HT_EXT_CONVERT, credits); + if (IS_ERR(handle)) { + ret =3D PTR_ERR(handle); + goto out_err; + } + + if (ioend->io_flags & IOMAP_IOEND_UNWRITTEN) { + ret =3D ext4_convert_unwritten_extents(handle, inode, pos, size); + if (ret) + goto out_journal; + } + + ret =3D ext4_iomap_wb_update_disksize(handle, inode, pos + size); +out_journal: + err =3D ext4_journal_stop(handle); + if (!ret) + ret =3D err; +out_err: + if (ret < 0 && !ext4_emergency_state(sb)) { + ext4_msg(sb, KERN_EMERG, + "failed to convert unwritten extents to written extents or update inod= e size -- potential data loss! (inode %llu, error %d)", + inode->i_ino, ret); + } +out: + iomap_finish_ioends(ioend, ret); +} + +/* + * Work on buffered iomap completed IO, to convert unwritten extents to + * mapped extents + */ +void ext4_iomap_end_io(struct work_struct *work) +{ + struct ext4_inode_info *ei =3D container_of(work, struct ext4_inode_info, + i_iomap_ioend_work); + struct iomap_ioend *ioend; + struct list_head ioend_list; + unsigned long flags; + + spin_lock_irqsave(&ei->i_completed_io_lock, flags); + list_replace_init(&ei->i_iomap_ioend_list, &ioend_list); + spin_unlock_irqrestore(&ei->i_completed_io_lock, flags); + + iomap_sort_ioends(&ioend_list); + while (!list_empty(&ioend_list)) { + ioend =3D list_entry(ioend_list.next, struct iomap_ioend, io_list); + list_del_init(&ioend->io_list); + iomap_ioend_try_merge(ioend, &ioend_list); + ext4_iomap_finish_ioend(ioend); + } +} + +void ext4_iomap_end_bio(struct bio *bio) +{ + struct iomap_ioend *ioend =3D iomap_ioend_from_bio(bio); + struct inode *inode =3D ioend->io_inode; + struct ext4_inode_info *ei =3D EXT4_I(inode); + struct ext4_sb_info *sbi =3D EXT4_SB(inode->i_sb); + unsigned long flags; + + /* Needs to convert unwritten extents or update the i_disksize. */ + if ((ioend->io_flags & IOMAP_IOEND_UNWRITTEN) || + ioend->io_offset + ioend->io_size > READ_ONCE(ei->i_disksize)) + goto defer; + + /* Needs to abort the journal on data_err=3Dabort. */ + if (unlikely(ioend->io_bio.bi_status)) + goto defer; + + iomap_finish_ioend(ioend, 0); + return; +defer: + spin_lock_irqsave(&ei->i_completed_io_lock, flags); + if (list_empty(&ei->i_iomap_ioend_list)) + queue_work(sbi->rsv_conversion_wq, &ei->i_iomap_ioend_work); + list_add_tail(&ioend->io_list, &ei->i_iomap_ioend_list); + spin_unlock_irqrestore(&ei->i_completed_io_lock, flags); +} diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 9bc294b769db..51d87db53543 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -123,7 +123,10 @@ static const struct fs_parameter_spec ext4_param_specs= []; * sb_start_write -> i_mutex -> transaction start -> i_data_sem (rw) * * writepages: - * transaction start -> page lock(s) -> i_data_sem (rw) + * - buffer_head path: + * transaction start -> folio lock(s) -> i_data_sem (rw) + * - iomap path: + * folio lock -> transaction start -> i_data_sem (rw) */ =20 static const struct fs_context_operations ext4_context_ops =3D { @@ -1428,10 +1431,12 @@ static struct inode *ext4_alloc_inode(struct super_= block *sb) #endif ei->jinode =3D NULL; INIT_LIST_HEAD(&ei->i_rsv_conversion_list); + INIT_LIST_HEAD(&ei->i_iomap_ioend_list); spin_lock_init(&ei->i_completed_io_lock); ei->i_sync_tid =3D 0; ei->i_datasync_tid =3D 0; INIT_WORK(&ei->i_rsv_conversion_work, ext4_end_io_rsv_work); + INIT_WORK(&ei->i_iomap_ioend_work, ext4_iomap_end_io); ext4_fc_init_inode(&ei->vfs_inode); spin_lock_init(&ei->i_fc_lock); mmb_init(&ei->i_metadata_bhs, &ei->vfs_inode.i_data); diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c index acf3cf98b23a..89bbd3027b81 100644 --- a/fs/iomap/ioend.c +++ b/fs/iomap/ioend.c @@ -305,7 +305,7 @@ ssize_t iomap_add_to_ioend(struct iomap_writepage_ctx *= wpc, struct folio *folio, } EXPORT_SYMBOL_GPL(iomap_add_to_ioend); =20 -static u32 iomap_finish_ioend(struct iomap_ioend *ioend, int error) +u32 iomap_finish_ioend(struct iomap_ioend *ioend, int error) { if (ioend->io_parent) { struct bio *bio =3D &ioend->io_bio; @@ -333,6 +333,7 @@ static u32 iomap_finish_ioend(struct iomap_ioend *ioend= , int error) return iomap_finish_ioend_buffered_read(ioend); return iomap_finish_ioend_buffered_write(ioend); } +EXPORT_SYMBOL_GPL(iomap_finish_ioend); =20 /* * Ioend completion routine for merged bios. This can only be called from = task diff --git a/include/linux/iomap.h b/include/linux/iomap.h index 2c5685adf3a9..7974ed441300 100644 --- a/include/linux/iomap.h +++ b/include/linux/iomap.h @@ -479,6 +479,7 @@ struct iomap_ioend *iomap_init_ioend(struct inode *inod= e, struct bio *bio, loff_t file_offset, u16 ioend_flags); struct iomap_ioend *iomap_split_ioend(struct iomap_ioend *ioend, unsigned int max_len, bool is_append); +u32 iomap_finish_ioend(struct iomap_ioend *ioend, int error); void iomap_finish_ioends(struct iomap_ioend *ioend, int error); void iomap_ioend_try_merge(struct iomap_ioend *ioend, struct list_head *more_ioends); --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 98632383C6E; Mon, 11 May 2026 07:28:36 +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=1778484519; cv=none; b=uvQJpA4WlFU/zZr9ATPotxh1HFUthnu0UCZuO2KXvG0oGp1kV0I45WT6KuEc5yx64Et9lyRLGL+gN1QoqkeD/Df6FZ89KpQ0+eYEk2bPdJigQYIid3s3Bnhmsfa5KEVFVEpDO+Cfhcang/NRcjL8612awm4e92CkB7Ee9q5BBMs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484519; c=relaxed/simple; bh=4XPqWCyq2Y3ogBER+i2c5iOzaYK5IQNCluqZ1OW8c7M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PiVtCfDiHYOBpgM6LkFli78XQc5bsT+hJf0LxKUUckZtfgAxJAOUEDj3TzIB++BH3ifUPbLLKGmWHErU2gGTL2vSBW8XkK75DOmYXA/Lxrfq+J0w38nx7uxFo+foJbVnaaJLFhdR4O2kHXrsKbYCUJLoHy9B9lot944D2PbVwW0= 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.198]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV4VkwzYQv2y; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 4AC6440579; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S14; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 10/23] ext4: implement mmap path using iomap Date: Mon, 11 May 2026 15:23:30 +0800 Message-ID: <20260511072344.191271-11-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S14 X-Coremail-Antispam: 1UD129KBjvJXoWxWFWfJr17Jryxuw47Xr18Zrb_yoW5KFWxpr 95KrWrGrsIqwna9rs7WFsrZr1YkayxtFW7WrW3Wr15ZFy2y340qa18KFyYvF4rJ3yxAr4I qF4jkr18W3W7CrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Introduce ext4_iomap_page_mkwrite() to implement the mmap iomap path for ext4. The heavy lifting is delegated to iomap_page_mkwrite(), which only requires ext4_iomap_buffered_write_ops and ext4_iomap_buffered_da_write_ops to allocate and map blocks. Note that the lock ordering between folio lock and transaction start in this path is reversed compared to the buffer_head buffered write path. The lock ordering documentation in super.c has been updated accordingly. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 32 +++++++++++++++++++++++++++++++- fs/ext4/super.c | 8 ++++++-- 2 files changed, 37 insertions(+), 3 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index a80195bd6f20..c6fe42d012fc 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4020,7 +4020,7 @@ static int ext4_iomap_buffered_do_write_begin(struct = inode *inode, return -ERANGE; if (WARN_ON_ONCE(!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) return -EINVAL; - if (WARN_ON_ONCE(!(flags & IOMAP_WRITE))) + if (WARN_ON_ONCE(!(flags & (IOMAP_WRITE | IOMAP_FAULT)))) return -EINVAL; =20 if (delalloc) @@ -4080,6 +4080,14 @@ static int ext4_iomap_buffered_da_write_end(struct i= node *inode, loff_t offset, if (iomap->type !=3D IOMAP_DELALLOC || !(iomap->flags & IOMAP_F_NEW)) return 0; =20 + /* + * iomap_page_mkwrite() will never fail in a way that requires delalloc + * extents that it allocated to be revoked. Hence never try to release + * them here. + */ + if (flags & IOMAP_FAULT) + return 0; + /* Nothing to do if we've written the entire delalloc extent */ start_byte =3D iomap_last_written_block(inode, offset, written); end_byte =3D round_up(offset + length, i_blocksize(inode)); @@ -7191,6 +7199,23 @@ static int ext4_block_page_mkwrite(struct inode *ino= de, struct folio *folio, return ret; } =20 +static vm_fault_t ext4_iomap_page_mkwrite(struct vm_fault *vmf) +{ + struct inode *inode =3D file_inode(vmf->vma->vm_file); + const struct iomap_ops *iomap_ops; + + /* + * ext4_nonda_switch() could writeback this folio, so have to + * call it before lock folio. + */ + if (test_opt(inode->i_sb, DELALLOC) && !ext4_nonda_switch(inode->i_sb)) + iomap_ops =3D &ext4_iomap_buffered_da_write_ops; + else + iomap_ops =3D &ext4_iomap_buffered_write_ops; + + return iomap_page_mkwrite(vmf, iomap_ops, NULL); +} + vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) { struct vm_area_struct *vma =3D vmf->vma; @@ -7213,6 +7238,11 @@ vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) =20 filemap_invalidate_lock_shared(mapping); =20 + if (ext4_inode_buffered_iomap(inode)) { + ret =3D ext4_iomap_page_mkwrite(vmf); + goto out; + } + err =3D ext4_convert_inline_data(inode); if (err) goto out_ret; diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 51d87db53543..62bfe05a64bc 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -100,8 +100,12 @@ static const struct fs_parameter_spec ext4_param_specs= []; * Lock ordering * * page fault path: - * mmap_lock -> sb_start_pagefault -> invalidate_lock (r) -> transaction s= tart - * -> page lock -> i_data_sem (rw) + * - buffer_head path: + * mmap_lock -> sb_start_pagefault -> invalidate_lock (r) -> + * transaction start -> folio lock -> i_data_sem (rw) + * - iomap path: + * mmap_lock -> sb_start_pagefault -> invalidate_lock (r) -> + * folio lock -> transaction start -> i_data_sem (rw) * * buffered write path: * sb_start_write -> i_rwsem (w) -> mmap_lock --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 7E1C73939C0; Mon, 11 May 2026 07:28:41 +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=1778484523; cv=none; b=QFW5/GVhoTVJyxE6SEiaVQiZqIz03XIBI6IBnP1O225qNOfEtWfnH73GvqxvEJlAKpST2sM0nGj/QIsSC3RxH6/hhxzf2adWtG5+n9hcXj0cKq/Sq7UupjwJWrqLRr14TYDJ3y5StjVeJ1Wl4lyIfZAPCIpWQ8Siake6qhha1iA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484523; c=relaxed/simple; bh=2wZ4jznOhPUYM8F9x4n6kgyHx1pEIWJdJlky+NdfO6Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hNHCQfWPdJJtdDMb68jRGAurJuZh8IwBnnSLYq4LnIXYZe13niN/qr/+GmghnTGq1ebv8NtFFh223a+7EfEThWtuFxRDOfqCMqqV4UP56ZKTieYtOyWQki+36v6tQdPk8psG1x0AnHdE/WTrry58ENcgZd9YhwlFZFOMdh122wQ= 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.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV5F4JzYQv34; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 64F954056E; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S15; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 11/23] iomap: correct the range of a partial dirty clear Date: Mon, 11 May 2026 15:23:31 +0800 Message-ID: <20260511072344.191271-12-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S15 X-Coremail-Antispam: 1UD129KBjvJXoW7ury5ArW5Wr4DKF1xuryDJrb_yoW8Zr4DpF s3KFs8KrWDX348ua4kZFW8XFnYya9rXF48JrW3Wwn3Wa15AF1FgF1v93y5uF97Kr47AF10 vF13trWxCr4DArJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The block range calculation in ifs_clear_range_dirty() is incorrect when partially clearing a range in a folio. We cannot clear the dirty bit of the first block or the last block if the start or end offset is not blocksize-aligned. This has not yet caused any issues since we always clear a whole folio in iomap_writeback_folio(). Fix this by rounding up the first block to blocksize alignment, and calculate the last block by rounding down (using truncation). Correct the nr_blks calculation accordingly. Signed-off-by: Zhang Yi --- This is modified from: https://lore.kernel.org/linux-fsdevel/20240812121159.3775074-2-yi.zhang@hu= aweicloud.com/ Changes: - Use round_up() instead of DIV_ROUND_UP() to prevent wasted integer division. fs/iomap/buffered-io.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index d7b648421a70..64351a448a8b 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -176,13 +176,17 @@ static void ifs_clear_range_dirty(struct folio *folio, { struct inode *inode =3D folio->mapping->host; unsigned int blks_per_folio =3D i_blocks_per_folio(inode, folio); - unsigned int first_blk =3D (off >> inode->i_blkbits); - unsigned int last_blk =3D (off + len - 1) >> inode->i_blkbits; - unsigned int nr_blks =3D last_blk - first_blk + 1; + unsigned int first_blk =3D round_up(off, i_blocksize(inode)) >> + inode->i_blkbits; + unsigned int last_blk =3D (off + len) >> inode->i_blkbits; unsigned long flags; =20 + if (first_blk >=3D last_blk) + return; + spin_lock_irqsave(&ifs->state_lock, flags); - bitmap_clear(ifs->state, first_blk + blks_per_folio, nr_blks); + bitmap_clear(ifs->state, first_blk + blks_per_folio, + last_blk - first_blk); spin_unlock_irqrestore(&ifs->state_lock, flags); } =20 --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 4BC13382F14; Mon, 11 May 2026 07:28:39 +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=1778484521; cv=none; b=jlasbNSSzlzZZnlI777ymUdSq2lVSiWkrCNxeLWrjngQyENw8YTbonpdskJa3xDWx/Cb46wCaMdmJJlHGv3cQBra7ssiRdWb6Kh2nFmFTu2w4TzadLxM39uiagGVY+g3ui/1i6jb0pldk04LxFbs7ug1IqiHQoIGUyJePOhmc9Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484521; c=relaxed/simple; bh=c7InR3i1MOiLg/Ny6xgdtX86ynRsTGo+NCviZ+z6mXE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dDlcNffQnv1SAyWfQoYvfsaSlXdFB/03IT/SaBNIKmrwqAYymWrYdkhvpMbnXWrYLzHaVld9MnG4t9kTNqIieY5A5dOg7rENLkTLc9RkmYqFT0UIVY4eG7MGnmKOKKzFDUV+aid+0m9F3HKTh7qZyX19S/kRjjfuUaSbNq2+RYc= 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.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXV65ryzYQv35; Mon, 11 May 2026 15:27:54 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 817FE4056F; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S16; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 12/23] iomap: support invalidating partial folios Date: Mon, 11 May 2026 15:23:32 +0800 Message-ID: <20260511072344.191271-13-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S16 X-Coremail-Antispam: 1UD129KBjvJXoW7uF1xtrW5Jw48tw18Kr4fAFb_yoW8CryrpF W3KrWDGryDGr17uw17Ca1fXF1j9a9xXFy7CFW3Gw1a9Fs8Jw1qgFy7Ka1YgayUJryxAF1S vrsFgFyvqF15A3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Current iomap_invalidate_folio() can only invalidate an entire folio. If we truncate a partial folio on a filesystem where the block size is smaller than the folio size, it will leave behind dirty bits for the truncated or punched blocks. During the write-back process, it will attempt to map the invalid hole range. Fortunately, this has not caused any real problems so far because the ->writeback_range() function corrects the length. However, the implementation of FALLOC_FL_ZERO_RANGE in ext4 depends on the support for invalidating partial folios. When ext4 partially zeroes out a dirty and unwritten folio, it does not perform a flush first like XFS. Therefore, if the dirty bits of the corresponding area cannot be cleared, the zeroed area after writeback remains in the written state rather than reverting to the unwritten state. Fix this by supporting invalidation of partial folios. Signed-off-by: Zhang Yi Reviewed-by: Darrick J. Wong --- This is cherry picked form: https://lore.kernel.org/linux-fsdevel/20240812121159.3775074-3-yi.zhang@hu= aweicloud.com/ No code changes, only update the commit message to explain why Ext4 needs this. fs/iomap/buffered-io.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 64351a448a8b..876c2f507f58 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -761,6 +761,8 @@ void iomap_invalidate_folio(struct folio *folio, size_t= offset, size_t len) WARN_ON_ONCE(folio_test_writeback(folio)); folio_cancel_dirty(folio); ifs_free(folio); + } else { + iomap_clear_range_dirty(folio, offset, len); } } EXPORT_SYMBOL_GPL(iomap_invalidate_folio); --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 2C1FF374E6D; Mon, 11 May 2026 07:28:26 +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=1778484510; cv=none; b=IA6SONadqljyKvP9bymcQDO+NQXjxKpNMmXkykvSdCPSHuGs9HszMT3LLD6swKGqcLk/rikbzJUiVyqrNoxlTld7L8Xsn8ZDTYEPGG0VOXl0pHlNtxavCRJwPPfV9wMNSzJdPQeoMqtcxlxMRAW5necZROtnQ+qzifEQ7mIBOHo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484510; c=relaxed/simple; bh=ZRjlGGFpGhbKsDKUIY6Uh38fsaCuluqJZzDsQ6eYbI0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JYjv3JXJXDM+POXHGePsKYSWeBweg6Ipk2PdfNsZI4kmpaabbVbZb2FFzMfKKm6sQGmEiRfSazm2USg6KBeGLoMdDPam//fFC3lCo10qLwYxXBJq0koBug+OvH2mj8MUDmmqEqC5SUmAo8hsOFopoED4yL0WQImSBHubgzeBJww= 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.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX50gQ9zKHMf8; Mon, 11 May 2026 15:27:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 9A3DC40578; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S17; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 13/23] iomap: fix incorrect did_zero setting in iomap_zero_iter() Date: Mon, 11 May 2026 15:23:33 +0800 Message-ID: <20260511072344.191271-14-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S17 X-Coremail-Antispam: 1UD129KBjvJXoWxJr1UJr4fuw1kXF18uw4kZwb_yoW8tr48p3 9xKayDCFn2qrW7WFn5JF9Ivr1Yywn5JrW7Wr4UGwn8ZF4qvr4akF1FgayYvF1xJ34fA3Wa yF4jyas2qF1UCrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The did_zero output parameter was unconditionally set after the loop, which is incorrect. It should only be set when the zeroing operation actually completes, not when IOMAP_F_STALE is set or when IOMAP_F_FOLIO_BATCH is set but !folio causes the loop to break early, or when iomap_iter_advance() returns an error. This causes did_zero to be incorrectly set when zeroing a clean unwritten extent because the loop exits early without actually zeroing any data. Fix it by using a local variable to track whether any folio was actually zeroed, and only set did_zero after the loop if zeroing happened. Signed-off-by: Zhang Yi Reviewed-by: "Darrick J. Wong" --- This is cherry picked form: https://lore.kernel.org/linux-fsdevel/20260310082250.3535486-1-yi.zhang@hu= aweicloud.com/ No changes. fs/iomap/buffered-io.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 876c2f507f58..27ab33edbdee 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1542,6 +1542,7 @@ static int iomap_zero_iter(struct iomap_iter *iter, b= ool *did_zero, const struct iomap_write_ops *write_ops) { u64 bytes =3D iomap_length(iter); + bool zeroed =3D false; int status; =20 do { @@ -1560,6 +1561,8 @@ static int iomap_zero_iter(struct iomap_iter *iter, b= ool *did_zero, /* a NULL folio means we're done with a folio batch */ if (!folio) { status =3D iomap_iter_advance_full(iter); + if (status) + return status; break; } =20 @@ -1570,6 +1573,7 @@ static int iomap_zero_iter(struct iomap_iter *iter, b= ool *did_zero, bytes); =20 folio_zero_range(folio, offset, bytes); + zeroed =3D true; folio_mark_accessed(folio); =20 ret =3D iomap_write_end(iter, bytes, bytes, folio); @@ -1579,10 +1583,10 @@ static int iomap_zero_iter(struct iomap_iter *iter,= bool *did_zero, =20 status =3D iomap_iter_advance(iter, bytes); if (status) - break; + return status; } while ((bytes =3D iomap_length(iter)) > 0); =20 - if (did_zero) + if (did_zero && zeroed) *did_zero =3D true; return status; } --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 EDBF0390222; Mon, 11 May 2026 07:28:38 +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=1778484521; cv=none; b=UuBX+/rSBve0w29Py5B0me03aL/xXKDMOetJkZwGnDQeT7pRroV51NRZ6bn8l7C/3jNum2TnggKdR02cQ9La3ThhNHmt3YSe/8YWAEKFkdjIIbDRveIVJoSQK7w0Ms3a7fpUZ2B9wkzDmTV4DWaHVtECNeepp0evfcEeCPUodpM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484521; c=relaxed/simple; bh=V3eMNYkfoQx4+ZrBSrx2zrbQ3uG/GQw9BBvAqfyrT4U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mRA+Bbj82iNk9Yyqy+ulCUwk04Agz6bz+SfYWUNgy9CG3AsX5irenOPuIbrI2/ezu42bM3ItMdOoo0RIBLmYgXo3FvH+p5tCd0jtzU6oyUoKwbBfcjLlhPn1Qq5OzPPatsepxg71SYAnB7TN/yPf5RuCp9v/Avx61TQ5g9qm4i0= 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.177]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXW0X6WzYQv3S; Mon, 11 May 2026 15:27:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id B3CEC40593; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S18; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 14/23] ext4: implement partial block zero range path using iomap Date: Mon, 11 May 2026 15:23:34 +0800 Message-ID: <20260511072344.191271-15-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S18 X-Coremail-Antispam: 1UD129KBjvJXoW3JryDZr15Kr4rWFWkArWxCrg_yoW7CFy8pa yDKry5GrsrWr9I9w4ftFsrXr1Yk3WftrW8Wry3Grn0v3s8XFWIkF48KFWFvF1jqw4xGw12 qF4jyFyxGF1UAaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Introduce a new iomap_ops instance, ext4_iomap_zero_ops, along with ext4_iomap_block_zero_range() to implement block zeroing via the iomap infrastructure for ext4. ext4_iomap_block_zero_range() calls iomap_zero_range() with ext4_iomap_zero_begin() as the callback. The callback locates and zeros out either a mapped partial block or a dirty, unwritten partial block. Important constraints: Zeroing out under an active journal handle can cause deadlock, because the order of acquiring the folio lock and starting a handle is inconsistent with the iomap writeback path. Therefore, ext4_iomap_block_zero_range(): - Must NOT be called under an active handle. - Cannot rely on data=3Dordered mode to ensure zeroed data persistence before updating i_disksize (for the cases of post-EOF append write, post-EOF fallocate, and truncate up). In subsequent patches, we will address this by synchronizing commit I/O but doesn't waiting for completion, and updating i_disksize to i_size only after the zeroed data has been written back. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index c6fe42d012fc..e0dae2501292 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4101,6 +4101,51 @@ static int ext4_iomap_buffered_da_write_end(struct i= node *inode, loff_t offset, return 0; } =20 +static int ext4_iomap_zero_begin(struct inode *inode, + loff_t offset, loff_t length, unsigned int flags, + struct iomap *iomap, struct iomap *srcmap) +{ + struct iomap_iter *iter =3D container_of(iomap, struct iomap_iter, iomap); + struct ext4_map_blocks map; + u8 blkbits =3D inode->i_blkbits; + unsigned int iomap_flags =3D 0; + int ret; + + ret =3D ext4_emergency_state(inode->i_sb); + if (unlikely(ret)) + return ret; + + if (WARN_ON_ONCE(!(flags & IOMAP_ZERO))) + return -EINVAL; + + ret =3D ext4_iomap_map_blocks(inode, offset, length, NULL, &map); + if (ret < 0) + return ret; + + /* + * Look up dirty folios for unwritten mappings within EOF. Providing + * this bypasses the flush iomap uses to trigger extent conversion + * when unwritten mappings have dirty pagecache in need of zeroing. + */ + if (map.m_flags & EXT4_MAP_UNWRITTEN) { + loff_t start =3D ((loff_t)map.m_lblk) << blkbits; + loff_t end =3D ((loff_t)map.m_lblk + map.m_len) << blkbits; + + iomap_fill_dirty_folios(iter, &start, end, &iomap_flags); + if ((start >> blkbits) < map.m_lblk + map.m_len) + map.m_len =3D (start >> blkbits) - map.m_lblk; + } + + ext4_set_iomap(inode, iomap, &map, offset, length, flags); + iomap->flags |=3D iomap_flags; + + return 0; +} + +static const struct iomap_ops ext4_iomap_zero_ops =3D { + .iomap_begin =3D ext4_iomap_zero_begin, +}; + /* * Since we always allocate unwritten extents, there is no need for * iomap_end to clean up allocated blocks on a short write. @@ -4616,6 +4661,47 @@ static int ext4_block_journalled_zero_range(struct i= node *inode, loff_t from, return err; } =20 +static int ext4_block_iomap_zero_range(struct inode *inode, loff_t from, + loff_t length, bool *did_zero, + bool *zero_written) +{ + int ret; + + /* + * Zeroing out under an active handle can cause deadlock since + * the order of acquiring the folio lock and starting a handle is + * inconsistent with the iomap writeback procedure. + */ + if (WARN_ON_ONCE(ext4_handle_valid(journal_current_handle()))) + return -EINVAL; + + /* The zeroing scope should not extend across a block. */ + if (WARN_ON_ONCE((from >> inode->i_blkbits) !=3D + ((from + length - 1) >> inode->i_blkbits))) + return -EINVAL; + + if (!(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ORPHAN_FS) && + !(inode_state_read_once(inode) & (I_NEW | I_FREEING))) + WARN_ON_ONCE(!inode_is_locked(inode) && + !rwsem_is_locked(&inode->i_mapping->invalidate_lock)); + + ret =3D iomap_zero_range(inode, from, length, did_zero, + &ext4_iomap_zero_ops, &ext4_iomap_write_ops, + NULL); + if (ret) + return ret; + + /* + * TODO: The iomap does not distinguish between different types of + * zeroing and always sets zero_written if a zeroing operation is + * performed, which may result in unnecessary order operations. + */ + if (did_zero && zero_written) + *zero_written =3D *did_zero; + + return 0; +} + /* * Zeros out a mapping of length 'length' starting from file offset * 'from'. The range to be zero'd must be contained with in one block. @@ -4642,6 +4728,9 @@ static int ext4_block_zero_range(struct inode *inode, } else if (ext4_should_journal_data(inode)) { return ext4_block_journalled_zero_range(inode, from, length, did_zero); + } else if (ext4_inode_buffered_iomap(inode)) { + return ext4_block_iomap_zero_range(inode, from, length, + did_zero, zero_written); } return ext4_block_do_zero_range(inode, from, length, did_zero, zero_written); @@ -4682,6 +4771,9 @@ int ext4_block_zero_eof(struct inode *inode, loff_t f= rom, loff_t end) * truncating up or performing an append write, because there might be * exposing stale on-disk data which may caused by concurrent post-EOF * mmap write during folio writeback. + * + * TODO: In the iomap path, handle this by updating i_disksize to + * i_size after the zeroed data has been written back. */ if (ext4_should_order_data(inode) && did_zero && zero_written && !IS_DAX(inode)) { --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 60F37390992; Mon, 11 May 2026 07:28:39 +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=1778484521; cv=none; b=B1dTwkCvGzbuMEEtSRWTWr2aazgn3YsPBJgKiWibOtuQBQqK6NkWf4xiewCY40zavtnZEG1fByLuo3Rh+JXAJ/5RX2dg3KiOE7NCr6KOc82eV5OGp1q4wnCo5TSlZG8QyWjSi6yYVsqRZB5q41Qv4klxYLC6HGL/SVENWtaqNjA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484521; c=relaxed/simple; bh=pTAy+2+kW0hd6ArJe/XxmdF9CJ4jwbhGmawCxMEgPoE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gF5o5RbIMsG9N1xVAX0JOXor7kYrhmEiRfC3ofDEi/jY1BxfUVTNn31i/xw+N2+jA62mvzwdfRGZKH8R9KcwcBWqr3520j/VpRosP9OkixLbEJ1y/+JIO+KemnEIuP4N5NLhZbJs6ZgopjcJWLEi/g0NnWri0ivNEduB2Qq8Arw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=none 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=none smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXW1B0tzYQv3b; Mon, 11 May 2026 15:27:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id CD6494056F; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S19; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 15/23] ext4: add block mapping tracepoints for iomap buffered I/O path Date: Mon, 11 May 2026 15:23:35 +0800 Message-ID: <20260511072344.191271-16-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S19 X-Coremail-Antispam: 1UD129KBjvJXoWxurW7ZrWDAFWkXF17WF18uFg_yoWrGr43pF yqyFy5KF4fXrsF9w4fWrW3XF1Fva1xKr4UGry3Wry5JFWxtr42gF4UGFyjyFy5Jw4jkryf WF4Ykry8G3WUuFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Add tracepoints for iomap buffered read, write, partial block zeroing, and writeback operations to help debug the iomap buffered I/O path. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 6 +++++ include/trace/events/ext4.h | 45 +++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index e0dae2501292..239d387ffaf2 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3961,6 +3961,8 @@ static int ext4_iomap_buffered_read_begin(struct inod= e *inode, loff_t offset, if (ret < 0) return ret; =20 + trace_ext4_iomap_buffered_read_begin(inode, &map, offset, length, + flags); ext4_set_iomap(inode, iomap, &map, offset, length, flags); return 0; } @@ -4034,6 +4036,8 @@ static int ext4_iomap_buffered_do_write_begin(struct = inode *inode, if (ret < 0) return ret; =20 + trace_ext4_iomap_buffered_write_begin(inode, &map, offset, length, + flags); ext4_set_iomap(inode, iomap, &map, offset, length, flags); return 0; } @@ -4136,6 +4140,7 @@ static int ext4_iomap_zero_begin(struct inode *inode, map.m_len =3D (start >> blkbits) - map.m_lblk; } =20 + trace_ext4_iomap_zero_begin(inode, &map, offset, length, flags); ext4_set_iomap(inode, iomap, &map, offset, length, flags); iomap->flags |=3D iomap_flags; =20 @@ -4308,6 +4313,7 @@ static int ext4_iomap_map_writeback_range(struct ioma= p_writepage_ctx *wpc, return ret; } out: + trace_ext4_iomap_map_writeback_range(inode, &map, offset, dirty_len, 0); ext4_set_iomap(inode, &wpc->iomap, &map, offset, dirty_len, 0); return 0; } diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h index f493642cf121..ebafa06cd191 100644 --- a/include/trace/events/ext4.h +++ b/include/trace/events/ext4.h @@ -3096,6 +3096,51 @@ TRACE_EVENT(ext4_move_extent_exit, __entry->ret) ); =20 +DECLARE_EVENT_CLASS(ext4_set_iomap_class, + TP_PROTO(struct inode *inode, struct ext4_map_blocks *map, + loff_t offset, loff_t length, unsigned int flags), + TP_ARGS(inode, map, offset, length, flags), + TP_STRUCT__entry( + __field(dev_t, dev) + __field(u64, ino) + __field(ext4_lblk_t, m_lblk) + __field(unsigned int, m_len) + __field(unsigned int, m_flags) + __field(u64, m_seq) + __field(loff_t, offset) + __field(loff_t, length) + __field(unsigned int, iomap_flags) + ), + TP_fast_assign( + __entry->dev =3D inode->i_sb->s_dev; + __entry->ino =3D inode->i_ino; + __entry->m_lblk =3D map->m_lblk; + __entry->m_len =3D map->m_len; + __entry->m_flags =3D map->m_flags; + __entry->m_seq =3D map->m_seq; + __entry->offset =3D offset; + __entry->length =3D length; + __entry->iomap_flags =3D flags; + + ), + TP_printk("dev %d:%d ino %llu m_lblk %u m_len %u m_flags %s m_seq %llu or= ig_off 0x%llx orig_len 0x%llx iomap_flags 0x%x", + MAJOR(__entry->dev), MINOR(__entry->dev), + __entry->ino, __entry->m_lblk, __entry->m_len, + show_mflags(__entry->m_flags), __entry->m_seq, + __entry->offset, __entry->length, __entry->iomap_flags) +) + +#define DEFINE_SET_IOMAP_EVENT(name) \ +DEFINE_EVENT(ext4_set_iomap_class, name, \ + TP_PROTO(struct inode *inode, struct ext4_map_blocks *map, \ + loff_t offset, loff_t length, unsigned int flags), \ + TP_ARGS(inode, map, offset, length, flags)) + +DEFINE_SET_IOMAP_EVENT(ext4_iomap_buffered_read_begin); +DEFINE_SET_IOMAP_EVENT(ext4_iomap_buffered_write_begin); +DEFINE_SET_IOMAP_EVENT(ext4_iomap_map_writeback_range); +DEFINE_SET_IOMAP_EVENT(ext4_iomap_zero_begin); + #endif /* _TRACE_EXT4_H */ =20 /* This part must be outside protection */ --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 7747937CD31; Mon, 11 May 2026 07:28:26 +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=1778484509; cv=none; b=gHdbEzajgN3/9JiEUKk/TyPWdw0kpZWEAigKwF35h6BHDxEKx55t7TSfGMMq3HcIPhhF2YrxdK0+y1DHvHP1II0zCLzMID8ZXcvaaysNV7wDetRPABPM2tVgHlfwuY5RrZ2JFO5RN3voimfEgwdVDlw8cO2Pr1IbZ/ohBmmcnzs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484509; c=relaxed/simple; bh=vZqBTaLK+H0HhZr53O/Wwz4dDyPOOoFrVwZvMbFkwcs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qc653OQ1o5Qcd+w+exfd5krAzhqTFCMC4oT7YmgiQl4V1SB1Srw9UA6F/jJyc7gcvlrO0PRQdJDMx/NQ+wSWmxliQWPtb5lgZ3IeKq5H2Hq1GnHKfhvlEY+TLdFi9CNypQ1tbzJRHrRLZJwLByVclJS9oQvz/fBF0o7DNtzuhtE= 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.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX52rLdzKHMfW; Mon, 11 May 2026 15:27:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id E170E40561; Mon, 11 May 2026 15:28:23 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S20; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 16/23] ext4: disable online defrag when inode using iomap buffered I/O path Date: Mon, 11 May 2026 15:23:36 +0800 Message-ID: <20260511072344.191271-17-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S20 X-Coremail-Antispam: 1UD129KBjvJXoW7Jw47Zry5AF43WFyxAFWxtFb_yoW8JrWfp3 Zakr1rGrWDX3WI9a9YqFnFqw4UKa1xGrW2grWSgr4UGFWDAF9Ygr4UKa15Aa4YqrWUJ34F qF42kr1UWw4UA3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Online defragmentation does not currently support inodes using the iomap buffered I/O path. The existing implementation relies on buffer_head for sub-folio block management and data=3Dordered mode for data consistency, both of which are incompatible with the iomap path. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/move_extent.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c index 3329b7ad5dbd..f707a1096544 100644 --- a/fs/ext4/move_extent.c +++ b/fs/ext4/move_extent.c @@ -476,6 +476,17 @@ static int mext_check_validity(struct inode *orig_inod= e, return -EOPNOTSUPP; } =20 + /* + * TODO: support online defrag for inodes that using the buffered + * I/O iomap path. + */ + if (ext4_inode_buffered_iomap(orig_inode) || + ext4_inode_buffered_iomap(donor_inode)) { + ext4_msg(sb, KERN_ERR, + "Online defrag not supported for inode with iomap buffered IO path"); + return -EOPNOTSUPP; + } + if (donor_inode->i_mode & (S_ISUID|S_ISGID)) { ext4_debug("ext4 move extent: suid or sgid is set to donor file [ino:ori= g %llu, donor %llu]\n", orig_inode->i_ino, donor_inode->i_ino); --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 36E5F386C22; Mon, 11 May 2026 07:28:33 +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=1778484515; cv=none; b=Q2nO37h8HfIs0rI7sOigvu8V/iuzSlKj+BBqja4XIVZwAPYgIcMavnMUUYh7+q+GnQjfkjM4zr1BkD6HrNgRjKUZJ+mDXsiyofrAlGIJUx2MA+R5610ATHS8IIgI3NqqN7jNtfGk5AJgk7C2MN0coVdtV00MlZAr2OmgFr+TRwA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484515; c=relaxed/simple; bh=Wpauh6dh+gZDkDxvmaaV/UYT72+kPYVxDhC/IIpMcgM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fVB2Lv3MKiJelQgOLklEub30NFbk8OaTI1fiyykpFRDqKDibhBMZfxqFa3c1scdNNG10hM9t3VrqU6slIJGUFUkh6WnSrN868dDqZQPoSQQe1W9iRJ62WzNmMkrWU3k1dVUYoJRvJEEb/N+9qMbLYGU5XMth0grO4JN6C3fDOpA= 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.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX53M65zKHMfg; Mon, 11 May 2026 15:27:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 0330040571; Mon, 11 May 2026 15:28:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S21; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 17/23] ext4: submit zeroed post-EOF data immediately in the iomap buffered I/O path Date: Mon, 11 May 2026 15:23:37 +0800 Message-ID: <20260511072344.191271-18-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S21 X-Coremail-Antispam: 1UD129KBjvJXoWxuF1UKr1rKr1fAry8uFyUJrb_yoWrGw47p3 y5K34rAr4DWF9F9wsaqF1xXr1akayfGw4UWFWxWw40vay3Ww18KF1Ik34FvFWUtr43Gay2 qF45AFWDW3WjyrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi In the generic buffered_head I/O path, we rely on the data=3Dorder mode to ensure that the zeroed EOF block data is written before updating i_disksize, thus preventing stale data from being exposed. However, the iomap buffered I/O path cannot use this mechanism. Instead, we issue the I/O immediately after performing the zero operation (without synchronous waiting for performance). This can reduce the risk of exposing stale data, but it does not guarantee that the zero data will be flushed to disk before the metadata of i_disksize is updated. The subsequent patches will wait for this I/O to complete before updating i_disksize. Suggested-by: Jan Kara Signed-off-by: Zhang Yi --- fs/ext4/inode.c | 66 ++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 55 insertions(+), 11 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 239d387ffaf2..e013aeb03d7b 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4742,6 +4742,32 @@ static int ext4_block_zero_range(struct inode *inode, zero_written); } =20 +static int ext4_iomap_submit_zero_block(struct inode *inode, + loff_t from, loff_t end) +{ + struct address_space *mapping =3D inode->i_mapping; + struct folio *folio; + bool do_submit =3D false; + + folio =3D filemap_lock_folio(mapping, from >> PAGE_SHIFT); + if (IS_ERR(folio)) + /* Already writeback and clear? */ + return PTR_ERR(folio) =3D=3D -ENOENT ? 0 : PTR_ERR(folio); + + folio_wait_writeback(folio); + WARN_ON_ONCE(folio_test_writeback(folio)); + + if (likely(folio_test_dirty(folio))) + do_submit =3D true; + folio_unlock(folio); + folio_put(folio); + + /* Submit zeroed block. */ + if (do_submit) + return filemap_fdatawrite_range(mapping, from, end - 1); + return 0; +} + /* * Zero out a mapping from file offset 'from' up to the end of the block * which corresponds to 'from' or to the given 'end' inside this block. @@ -4765,8 +4791,10 @@ int ext4_block_zero_eof(struct inode *inode, loff_t = from, loff_t end) if (IS_ENCRYPTED(inode) && !fscrypt_has_encryption_key(inode)) return 0; =20 - if (length > blocksize - offset) + if (length > blocksize - offset) { length =3D blocksize - offset; + end =3D from + length; + } =20 err =3D ext4_block_zero_range(inode, from, length, &did_zero, &zero_written); @@ -4781,18 +4809,34 @@ int ext4_block_zero_eof(struct inode *inode, loff_t= from, loff_t end) * TODO: In the iomap path, handle this by updating i_disksize to * i_size after the zeroed data has been written back. */ - if (ext4_should_order_data(inode) && - did_zero && zero_written && !IS_DAX(inode)) { - handle_t *handle; + if (did_zero && zero_written && !IS_DAX(inode)) { + if (ext4_should_order_data(inode)) { + handle_t *handle; =20 - handle =3D ext4_journal_start(inode, EXT4_HT_MISC, 1); - if (IS_ERR(handle)) - return PTR_ERR(handle); + handle =3D ext4_journal_start(inode, EXT4_HT_MISC, 1); + if (IS_ERR(handle)) + return PTR_ERR(handle); =20 - err =3D ext4_jbd2_inode_add_write(handle, inode, from, length); - ext4_journal_stop(handle); - if (err) - return err; + err =3D ext4_jbd2_inode_add_write(handle, inode, from, + length); + ext4_journal_stop(handle); + if (err) + return err; + /* + * inodes using the iomap buffered I/O path do not use the + * data=3Dordered mode. We submit zeroed range directly here. + * Do not wait for I/O completion for performance. + * + * TODO: Any operation that extends i_disksize (including + * append write end io past the zeroed boundary, truncate up, + * and append fallocate) must wait for the relevant I/O to + * complete before updating i_disksize. + */ + } else if (ext4_inode_buffered_iomap(inode)) { + err =3D ext4_iomap_submit_zero_block(inode, from, end); + if (err) + return err; + } } =20 return 0; --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 43995383C84; Mon, 11 May 2026 07:28:38 +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=1778484520; cv=none; b=gKe+CWMsPYUDRYlCe9cTg3s0QPrj+8blwevfUcY/sV/pKE8OlRd54y6rDQAP9h/6f8CZq2t1EI5cVGi2v6lJ+SiuxDkc8UTulRgRQ+4GTDjLtaHIUnHhGficcN0PaJp493zcU1eGLtpofa3jzbsx1yrr/z+nwehS56ZP4xj+x+Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484520; c=relaxed/simple; bh=kvPnJ7yVd9n6VcDpIsH2Rscp+rR5KnGoerAy64lgD1M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N0GLU0NdgZPs0AXPrT6JFwRUFWa0J0EJnuw0pTJBnXlM/d/s/v0wfArlMbdK9iM8iTmRTDTmD4S+polgm0WT7m2je/oj2+6T7P4yJQXoKQUuAY9OpmzTv2+Q+XS/oeRy1DC1YVI5p9ej+vXaaRUgh56OIDQGP+249Lew+5VkxJ0= 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.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXW33FLzYQv1r; Mon, 11 May 2026 15:27:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 198BA4056F; Mon, 11 May 2026 15:28:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S22; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 18/23] ext4: wait for ordered I/O in the iomap buffered I/O path Date: Mon, 11 May 2026 15:23:38 +0800 Message-ID: <20260511072344.191271-19-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S22 X-Coremail-Antispam: 1UD129KBjvJXoW3KFW7Aw4rGry5GFy7ArWrKrg_yoWDKrWxpF ZxGryrGw48XF929rs2qw48Zr1F93WrKayrJFWfWw4qvay5GryIkF18tF15ZFyUtrZrJrWI qF48ArW7Wr1DJrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi For append writes, wait for ordered I/O to complete before updating i_disksize. This ensures that zeroed data is flushed to disk before the metadata update, preventing stale data from being exposed during unaligned post-EOF append writes. Suggested-by: Jan Kara Signed-off-by: Zhang Yi --- fs/ext4/ext4.h | 11 +++++++ fs/ext4/inode.c | 80 ++++++++++++++++++++++++++++++++++++++++++----- fs/ext4/page-io.c | 60 +++++++++++++++++++++++++++++++++++ fs/ext4/super.c | 23 ++++++++++---- 4 files changed, 161 insertions(+), 13 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 078feda47e36..9ce2128eea3e 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1195,6 +1195,15 @@ struct ext4_inode_info { #ifdef CONFIG_FS_ENCRYPTION struct fscrypt_inode_info *i_crypt_info; #endif + + /* + * Track ordered zeroed data during post-EOF append writes, fallocate, + * and truncate-up operations. These parameters are used only in the + * iomap buffered I/O path. + */ + ext4_lblk_t i_ordered_lblk; + ext4_lblk_t i_ordered_len; + wait_queue_head_t i_ordered_wq; }; =20 /* @@ -3858,6 +3867,8 @@ extern int ext4_move_extents(struct file *o_filp, str= uct file *d_filp, __u64 len, __u64 *moved_len); =20 /* page-io.c */ +#define EXT4_IOMAP_IOEND_ORDER_IO 1UL /* This I/O is an ordered one */ + extern int __init ext4_init_pageio(void); extern void ext4_exit_pageio(void); extern ext4_io_end_t *ext4_init_io_end(struct inode *inode, gfp_t flags); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index e013aeb03d7b..11fb369efeb1 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4345,6 +4345,7 @@ static int ext4_iomap_writeback_submit(struct iomap_w= ritepage_ctx *wpc, { struct iomap_ioend *ioend =3D wpc->wb_ctx; struct ext4_inode_info *ei =3D EXT4_I(ioend->io_inode); + ext4_lblk_t start, end, order_lblk, order_len; =20 /* * After I/O completion, a worker needs to be scheduled when: @@ -4357,6 +4358,30 @@ static int ext4_iomap_writeback_submit(struct iomap_= writepage_ctx *wpc, test_opt(ioend->io_inode->i_sb, DATA_ERR_ABORT)) ioend->io_bio.bi_end_io =3D ext4_iomap_end_bio; =20 + /* + * Mark the I/O as ordered. Ordered I/O requires separate endio + * handling and must not be merged with regular I/O operations. + */ + order_len =3D READ_ONCE(ei->i_ordered_len); + if (order_len) { + /* + * Pair with smp_store_release() in ext4_block_zero_eof(). + * Ensure we see the updated i_ordered_lblk that was written + * before the release store to i_ordered_len. + */ + smp_rmb(); + order_lblk =3D READ_ONCE(ei->i_ordered_lblk); + start =3D ioend->io_offset >> ioend->io_inode->i_blkbits; + end =3D EXT4_B_TO_LBLK(ioend->io_inode, + ioend->io_offset + ioend->io_size); + + if (start <=3D order_lblk && end >=3D order_lblk + order_len) { + ioend->io_bio.bi_end_io =3D ext4_iomap_end_bio; + ioend->io_private =3D (void *)EXT4_IOMAP_IOEND_ORDER_IO; + ioend->io_flags |=3D IOMAP_IOEND_BOUNDARY; + } + } + return iomap_ioend_writeback_submit(wpc, error); } =20 @@ -4746,8 +4771,10 @@ static int ext4_iomap_submit_zero_block(struct inode= *inode, loff_t from, loff_t end) { struct address_space *mapping =3D inode->i_mapping; + struct ext4_inode_info *ei =3D EXT4_I(inode); struct folio *folio; bool do_submit =3D false; + int ret; =20 folio =3D filemap_lock_folio(mapping, from >> PAGE_SHIFT); if (IS_ERR(folio)) @@ -4757,14 +4784,50 @@ static int ext4_iomap_submit_zero_block(struct inod= e *inode, folio_wait_writeback(folio); WARN_ON_ONCE(folio_test_writeback(folio)); =20 - if (likely(folio_test_dirty(folio))) + /* + * Mark the ordered range. It will be cleared upon I/O completion + * in ext4_iomap_end_bio(). Any operation that extends i_disksize + * (including append write end io past the zeroed boundary, + * truncate up and append fallocate) must wait for this I/O to + * complete before updating i_disksize. + * + * When multiple overlapping unaligned EOF writes are in flight, we + * only need to track and wait for the first one. Subsequent writes + * will zero the gap in memory and ensure that the zeroed data is + * written out along with the valid data in the same block before + * i_disksize is updated. + */ + if (likely(folio_test_dirty(folio) && + READ_ONCE(ei->i_ordered_len) =3D=3D 0)) { + WRITE_ONCE(ei->i_ordered_lblk, + from >> inode->i_blkbits); + /* + * Pairs with smp_rmb() in ext4_iomap_writeback_submit() + * and ext4_iomap_wb_ordered_wait(). Ensure the updated + * i_ordered_lblk is visible when i_ordered_len becomes + * non-zero. + */ + smp_store_release(&ei->i_ordered_len, 1); do_submit =3D true; + } folio_unlock(folio); folio_put(folio); =20 /* Submit zeroed block. */ - if (do_submit) - return filemap_fdatawrite_range(mapping, from, end - 1); + if (do_submit) { + ret =3D filemap_fdatawrite_range(mapping, from, end - 1); + if (ret) { + /* + * Pairs with wait_event() in + * ext4_iomap_wb_ordered_wait(). Ensure + * i_ordered_len =3D 0 is visible before waking up + * waiters. + */ + smp_store_release(&ei->i_ordered_len, 0); + wake_up_all(&ei->i_ordered_wq); + return ret; + } + } return 0; } =20 @@ -4827,10 +4890,13 @@ int ext4_block_zero_eof(struct inode *inode, loff_t= from, loff_t end) * data=3Dordered mode. We submit zeroed range directly here. * Do not wait for I/O completion for performance. * - * TODO: Any operation that extends i_disksize (including - * append write end io past the zeroed boundary, truncate up, - * and append fallocate) must wait for the relevant I/O to - * complete before updating i_disksize. + * The end_io handler ext4_iomap_wb_ordered_wait() will wait + * for I/O completion before updating i_disksize if the write + * extends beyond the zeroed boundary. + * + * TODO: Any other operation that extends i_disksize + * (including truncate up and append fallocate) must wait for + * the relevant I/O to complete before updating i_disksize. */ } else if (ext4_inode_buffered_iomap(inode)) { err =3D ext4_iomap_submit_zero_block(inode, from, end); diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c index 3050c887329f..ad05ebb49bf6 100644 --- a/fs/ext4/page-io.c +++ b/fs/ext4/page-io.c @@ -613,6 +613,46 @@ int ext4_bio_write_folio(struct ext4_io_submit *io, st= ruct folio *folio, return 0; } =20 +/* + * If the old disk size is not block size aligned and the current + * writeback range is entirely beyond the old EOF block, we should + * wait for the zeroed data written in ext4_block_zero_eof() to be + * written out, otherwise, it may expose stale data in that block. + */ +static void ext4_iomap_wb_ordered_wait(struct inode *inode, + loff_t pos, loff_t end) +{ + struct ext4_inode_info *ei =3D EXT4_I(inode); + unsigned int blocksize =3D i_blocksize(inode); + loff_t disksize =3D READ_ONCE(ei->i_disksize); + ext4_lblk_t order_lblk, order_len; + + /* + * Waiting for ordered I/O is unnecessary when: + * - The on-disk size is block-aligned (no stale data exists). + * - The write start is within the block of the old EOF + * (overwriting, or appending to a block that already contains + * valid data). + */ + if (!(disksize & (blocksize - 1)) || + pos < round_up(disksize, blocksize)) + return; + + order_len =3D READ_ONCE(ei->i_ordered_len); + if (!order_len) + return; + + /* + * Pair with smp_store_release() in ext4_iomap_end_bio() and + * ext4_block_zero_eof(). Ensure we see the updated i_ordered_lblk + * that was written before the release store to i_ordered_len. + */ + smp_rmb(); + order_lblk =3D READ_ONCE(ei->i_ordered_lblk); + if ((pos >> inode->i_blkbits) >=3D order_lblk + order_len) + wait_event(ei->i_ordered_wq, READ_ONCE(ei->i_ordered_len) =3D=3D 0); +} + static int ext4_iomap_wb_update_disksize(handle_t *handle, struct inode *i= node, loff_t end) { @@ -656,6 +696,9 @@ static void ext4_iomap_finish_ioend(struct iomap_ioend = *ioend) goto out; } =20 + /* Wait ordered zero data to be written out. */ + ext4_iomap_wb_ordered_wait(inode, pos, pos + size); + /* We may need to convert one extent and dirty the inode. */ credits =3D ext4_chunk_trans_blocks(inode, EXT4_MAX_BLOCKS(size, pos, inode->i_blkbits)); @@ -717,8 +760,25 @@ void ext4_iomap_end_bio(struct bio *bio) struct inode *inode =3D ioend->io_inode; struct ext4_inode_info *ei =3D EXT4_I(inode); struct ext4_sb_info *sbi =3D EXT4_SB(inode->i_sb); + unsigned long io_mode =3D (unsigned long)ioend->io_private; unsigned long flags; =20 + /* + * This is an ordered I/O, clear the ordered range set in + * ext4_block_zero_eof() and wake up all waiters that will update + * the inode i_disksize. + */ + if (io_mode =3D=3D EXT4_IOMAP_IOEND_ORDER_IO) { + /* + * Pairs with wait_event() in ext4_iomap_wb_ordered_wait(). + * Ensure i_ordered_len =3D 0 is visible before waking up + * waiters. + */ + smp_store_release(&ei->i_ordered_len, 0); + wake_up_all(&ei->i_ordered_wq); + goto defer; + } + /* Needs to convert unwritten extents or update the i_disksize. */ if ((ioend->io_flags & IOMAP_IOEND_UNWRITTEN) || ioend->io_offset + ioend->io_size > READ_ONCE(ei->i_disksize)) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 62bfe05a64bc..9c0a00e716f3 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1444,6 +1444,9 @@ static struct inode *ext4_alloc_inode(struct super_bl= ock *sb) ext4_fc_init_inode(&ei->vfs_inode); spin_lock_init(&ei->i_fc_lock); mmb_init(&ei->i_metadata_bhs, &ei->vfs_inode.i_data); + ei->i_ordered_lblk =3D 0; + ei->i_ordered_len =3D 0; + init_waitqueue_head(&ei->i_ordered_wq); return &ei->vfs_inode; } =20 @@ -1480,12 +1483,20 @@ static void ext4_destroy_inode(struct inode *inode) dump_stack(); } =20 - if (!(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ERROR_FS) && - WARN_ON_ONCE(EXT4_I(inode)->i_reserved_data_blocks)) - ext4_msg(inode->i_sb, KERN_ERR, - "Inode %llu (%p): i_reserved_data_blocks (%u) not cleared!", - inode->i_ino, EXT4_I(inode), - EXT4_I(inode)->i_reserved_data_blocks); + if (!(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ERROR_FS)) { + if (WARN_ON_ONCE(EXT4_I(inode)->i_reserved_data_blocks)) + ext4_msg(inode->i_sb, KERN_ERR, + "Inode %llu (%p): i_reserved_data_blocks (%u) not cleared!", + inode->i_ino, EXT4_I(inode), + EXT4_I(inode)->i_reserved_data_blocks); + + if (WARN_ON_ONCE(EXT4_I(inode)->i_ordered_len)) + ext4_msg(inode->i_sb, KERN_ERR, + "Inode %llu (%p): i_ordered_lblk (%u) and i_ordered_len (%u) not clea= red!", + inode->i_ino, EXT4_I(inode), + EXT4_I(inode)->i_ordered_lblk, + EXT4_I(inode)->i_ordered_len); + } } =20 static void ext4_shutdown(struct super_block *sb) --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [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 626E639934A; Mon, 11 May 2026 07:28:43 +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=1778484526; cv=none; b=SXAITSUejsHYtsFow8DWkEVKql4khecOrAcBxW1Bs8+OYvZzK7MWB+f9m7YTAIAmDR2ekprcDOJmJU9YvqwbtOHjpM6UuF4sftvQ3oIcRLBGWtah/hSFCr1V0tTqdkIx0HfjPSxKBtmz7lTpP0hY5Cqbgn2srOkr7uhqM/auMxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484526; c=relaxed/simple; bh=ICkPKQHha3eXpAuWdrMJR8Vcj4myBIwUbNb1f1AnKJQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rUykNk7LPGURPrPlLf4ulsKEQoLkstyuvYPp+ERAvFnOLSIhb8UZGXYW5G1nuEGt+3K1tUgxKrRb54RMNsmXCXVH+o/TYIE5oqcSdw2z6vlZxMq3vNHfGZ7OZ65OlLLqeepNxFXm7RkJG1QWCFZJuJ8tk9yPrefleXCKV6syfJ0= 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.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gDWXW3ZzFzYQv3s; Mon, 11 May 2026 15:27:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 2A8A84056B; Mon, 11 May 2026 15:28:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S23; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 19/23] ext4: update i_disksize to i_size on ordered I/O completion Date: Mon, 11 May 2026 15:23:39 +0800 Message-ID: <20260511072344.191271-20-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S23 X-Coremail-Antispam: 1UD129KBjvJXoWxtr47uryxur1kJFyxtw17GFg_yoWfGr17pr W5K34rAw1vq3sa9rs7Xry0qw1Fva1rGw48JFy7ur4vvFy5Cws2vF1xtryfuFW8trZ3Jw4j qFWktr48Wr1kAw7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Currently, i_disksize is updated after ordered data writeback to prevent exposing stale data in the post-EOF block. However, operations like append allocate, zero range and truncate update i_disksize directly. If the new i_disksize exceeds the original value, metadata may be written back before the zeroed data is persisted. To avoid this, we defer i_disksize updates when i_ordered_len is non-zero, only applying them after ordered I/O completes. However, this deferral introduces a new problem: on ordered I/O completion, i_disksize is updated only to the end of that specific I/O, discarding any later updates (e.g., from fallocate) and causing filesystem inconsistency. A potential fix would involve scanning for dirty or writeback folios beyond the current position, then updating i_disksize to the start of the first such folio or to i_size. However, folio scanning is expensive and concurrency with operations like fallocate makes this approach prohibitively complex. Instead, when ordered zero I/O completes, update i_disksize directly to i_size. This may expose zeroed data (if dirty data within the range is not yet on disk after crash recovery), but it will never expose stale data. This limitation is restricted to unaligned append writes and is deemed acceptable. Suggested-by: Jan Kara Signed-off-by: Zhang Yi --- fs/ext4/ext4.h | 29 +++++++++++++++++++++++++---- fs/ext4/inode.c | 30 ++++++++++++++++++++---------- fs/ext4/page-io.c | 25 ++++++++++++++++++++----- 3 files changed, 65 insertions(+), 19 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 9ce2128eea3e..0a3bb44f1e6e 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -3493,13 +3493,21 @@ do { \ #define EXT4_FREECLUSTERS_WATERMARK 0 #endif =20 -/* Update i_disksize. Requires i_rwsem to avoid races with truncate */ +/* + * Update i_disksize. Requires i_rwsem to avoid races with truncate. + * + * In the iomap buffered I/O path, a non-zero i_ordered_len indicates that + * an ordered I/O (zeroing the EOF partial block) is still in progress. + * In that case, i_disksize will be updated after the ordered data has + * been written out. + */ static inline void ext4_update_i_disksize(struct inode *inode, loff_t news= ize) { WARN_ON_ONCE(S_ISREG(inode->i_mode) && !inode_is_locked(inode)); down_write(&EXT4_I(inode)->i_data_sem); - if (newsize > EXT4_I(inode)->i_disksize) + if (newsize > EXT4_I(inode)->i_disksize && + READ_ONCE(EXT4_I(inode)->i_ordered_len) =3D=3D 0) WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize); up_write(&EXT4_I(inode)->i_data_sem); } @@ -3514,8 +3522,21 @@ static inline int ext4_update_inode_size(struct inod= e *inode, loff_t newsize) changed =3D 1; } if (newsize > EXT4_I(inode)->i_disksize) { - ext4_update_i_disksize(inode, newsize); - changed |=3D 2; + /* + * Pairs with smp_store_release() in ext4_iomap_end_bio() + * that clears i_ordered_len. The smp_mb() ensures the + * i_size store above is globally visible before we read + * i_ordered_len. This way, if we skip the i_disksize + * update because i_ordered_len is still non-zero, the + * ordered-I/O completion path (which reads i_size under + * i_data_sem) is guaranteed to see the new i_size and will + * update i_disksize correctly. + */ + smp_mb(); + if (READ_ONCE(EXT4_I(inode)->i_ordered_len) =3D=3D 0) { + ext4_update_i_disksize(inode, newsize); + changed |=3D 2; + } } return changed; } diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 11fb369efeb1..1e208b3fad34 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4868,9 +4868,6 @@ int ext4_block_zero_eof(struct inode *inode, loff_t f= rom, loff_t end) * truncating up or performing an append write, because there might be * exposing stale on-disk data which may caused by concurrent post-EOF * mmap write during folio writeback. - * - * TODO: In the iomap path, handle this by updating i_disksize to - * i_size after the zeroed data has been written back. */ if (did_zero && zero_written && !IS_DAX(inode)) { if (ext4_should_order_data(inode)) { @@ -4894,9 +4891,15 @@ int ext4_block_zero_eof(struct inode *inode, loff_t = from, loff_t end) * for I/O completion before updating i_disksize if the write * extends beyond the zeroed boundary. * - * TODO: Any other operation that extends i_disksize - * (including truncate up and append fallocate) must wait for - * the relevant I/O to complete before updating i_disksize. + * When zeroed I/O is in progress, operations that extend + * i_disksize are handled as follows: + * + * - Truncate up, append fallocate and zero_range: + * Defer the update. The file size will be updated to + * i_size by the end_io handler once the ongoing I/O + * completes. + * + * - TODO: handle insert range and collapse range. */ } else if (ext4_inode_buffered_iomap(inode)) { err =3D ext4_iomap_submit_zero_block(inode, from, end); @@ -6512,11 +6515,16 @@ static void ext4_wait_for_tail_page_commit(struct i= node *inode) } =20 /* - * Set i_size and i_disksize to 'newsize'. + * Set i_size and i_disksize to 'newsize'. In the iomap buffered I/O path, + * if i_ordered_len is non-zero and newsize exceeds the current i_disksize, + * the actual i_disksize update is deferred until after the ordered data is + * written out. In that case, i_disksize will be set to i_size upon I/O + * completion. * * Both i_rwsem and i_data_sem are required here to avoid races between - * generic append writeback and concurrent truncate that also modify - * i_size and i_disksize. + * generic append writeback (or ordered I/O writeback) and concurrent + * operations (e.g., fallocate, truncate) that also modify i_size and + * i_disksize. */ static inline void ext4_set_inode_size(struct inode *inode, loff_t newsize) { @@ -6524,7 +6532,9 @@ static inline void ext4_set_inode_size(struct inode *= inode, loff_t newsize) =20 down_write(&EXT4_I(inode)->i_data_sem); i_size_write(inode, newsize); - EXT4_I(inode)->i_disksize =3D newsize; + if (READ_ONCE(EXT4_I(inode)->i_ordered_len) =3D=3D 0 || + newsize < EXT4_I(inode)->i_disksize) + WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize); up_write(&EXT4_I(inode)->i_data_sem); } =20 diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c index ad05ebb49bf6..2ad9f900c9f3 100644 --- a/fs/ext4/page-io.c +++ b/fs/ext4/page-io.c @@ -654,13 +654,13 @@ static void ext4_iomap_wb_ordered_wait(struct inode *= inode, } =20 static int ext4_iomap_wb_update_disksize(handle_t *handle, struct inode *i= node, - loff_t end) + loff_t end, bool is_ordered) { - loff_t new_disksize =3D end; + loff_t new_disksize, i_size; struct ext4_inode_info *ei =3D EXT4_I(inode); int ret; =20 - if (new_disksize <=3D READ_ONCE(ei->i_disksize)) + if (end <=3D READ_ONCE(ei->i_disksize) && !is_ordered) return 0; =20 /* @@ -668,7 +668,20 @@ static int ext4_iomap_wb_update_disksize(handle_t *han= dle, struct inode *inode, * are avoided by checking i_size under i_data_sem. */ down_write(&ei->i_data_sem); - new_disksize =3D min(new_disksize, i_size_read(inode)); + i_size =3D i_size_read(inode); + + /* + * Update i_disksize to i_size when completing an ordered I/O that + * zeroes the old EOF partial block. This is safe because we never + * directly allocate written blocks during buffered writes. + * + * This ensures i_disksize is correctly advanced during truncate-up + * or append fallocate on a block-unaligned file, preventing it + * from remaining stale. A downside is that zeroed data may be + * exposed after crash recovery if the dirty data in this range is + * not yet on disk, but stale data will never be exposed. + */ + new_disksize =3D is_ordered ? i_size : min(end, i_size); if (new_disksize > ei->i_disksize) ei->i_disksize =3D new_disksize; up_write(&ei->i_data_sem); @@ -685,6 +698,7 @@ static void ext4_iomap_finish_ioend(struct iomap_ioend = *ioend) struct super_block *sb =3D inode->i_sb; loff_t pos =3D ioend->io_offset; size_t size =3D ioend->io_size; + unsigned long io_mode =3D (unsigned long)ioend->io_private; handle_t *handle; int credits; int ret, err; @@ -714,7 +728,8 @@ static void ext4_iomap_finish_ioend(struct iomap_ioend = *ioend) goto out_journal; } =20 - ret =3D ext4_iomap_wb_update_disksize(handle, inode, pos + size); + ret =3D ext4_iomap_wb_update_disksize(handle, inode, pos + size, + io_mode =3D=3D EXT4_IOMAP_IOEND_ORDER_IO); out_journal: err =3D ext4_journal_stop(handle); if (!ret) --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 49483388E5A; Mon, 11 May 2026 07:28:35 +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=1778484517; cv=none; b=k6d1eWEt3l8l1QsdAfmNZpQLbnOIkImMoZbged5h3/dm1OJX3UimEE/0hY3LVNFY9DDgHlcp6WmHz/VQOHKNXW8A/6Tu3EbdC679R/ZygOWI27Oo0XzqjG8iJAxyeRJ8AIt1RCQbBaaT0cBm3Gn8KdekixoFgPls/T+KOft3n0k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484517; c=relaxed/simple; bh=lpABSLQe57xHGvtOsXpd4YUWod4lWlx6xy4V7JrXUL4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ba5aag2YdK88KpAFhbGdcPMus0wXk25aWcmbjAKDva8xumt7rlyZfHUZsmAwgr55Y+P59UTV1o5UsSc2T6YaaBxyPN3wizLaS7tVFjO6KFvR/AmetAUnETKARBstqcNEpcKoVyTNIofq+ZybPJ0UqUayBXquLt+gTDYkIQCa0lc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=none 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=none smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX54x6DzKHMfw; Mon, 11 May 2026 15:27:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 382634056E; Mon, 11 May 2026 15:28:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S24; Mon, 11 May 2026 15:28:23 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 20/23] ext4: wait for ordered I/O to complete during insert and collapse range Date: Mon, 11 May 2026 15:23:40 +0800 Message-ID: <20260511072344.191271-21-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S24 X-Coremail-Antispam: 1UD129KBjvJXoWxGF18GFyUur1Duw1kuFWfKrg_yoW5KFWkpr WfK3y8GF48X34q9rs2qFZrZw1Fga1rKw48JFWfurWqvay5G34IvFn0yFy0kFW8trZ8JrWj qF4kK3y7Xw18A3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW5JVW7JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Currently, i_disksize is updated after ordered data writeback to prevent exposing stale data in the post-EOF block, and operations like append allocate, zero range, and truncate defer the i_disksize update until ordered I/O completes. However, insert range and collapse range still directly update i_disksize. This is safe because they have already called filemap_write_and_wait_range() to flush data up to LLONG_MAX, ensuring that ordered I/O has completed if any dirty data was present. One exception is when the ordered I/O is caused by a previous truncate up. In this case, there is no dirty data to flush. Therefore, add an explicit wait for I/O completion to handle this case. This will not have significant impact on performance. Finally, also add a WARN_ON_ONCE check before updating i_disksize to detect any unexpected cases that could still expose stale data. Signed-off-by: Zhang Yi --- fs/ext4/extents.c | 18 ++++++++++++++++++ fs/ext4/inode.c | 4 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 125f628e738a..85c74c37f0ca 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -5565,6 +5565,14 @@ static int ext4_collapse_range(struct file *file, lo= ff_t offset, loff_t len) if (ret) return ret; =20 + /* + * Wait for ordered I/O to be complete. Updating i_disksize beyond + * the current i_disksize here risks exposuring stale data. + */ + if (ext4_inode_buffered_iomap(inode)) + wait_event(EXT4_I(inode)->i_ordered_wq, + READ_ONCE(EXT4_I(inode)->i_ordered_len) =3D=3D 0); + truncate_pagecache(inode, start); =20 credits =3D ext4_chunk_trans_extent(inode, 0); @@ -5597,6 +5605,7 @@ static int ext4_collapse_range(struct file *file, lof= f_t offset, loff_t len) goto out_handle; } =20 + WARN_ON_ONCE(READ_ONCE(EXT4_I(inode)->i_ordered_len) !=3D 0); new_size =3D inode->i_size - len; i_size_write(inode, new_size); EXT4_I(inode)->i_disksize =3D new_size; @@ -5661,6 +5670,14 @@ static int ext4_insert_range(struct file *file, loff= _t offset, loff_t len) if (ret) return ret; =20 + /* + * Wait for ordered I/O to be complete. Updating i_disksize beyond + * the current i_disksize here risks exposuring stale data. + */ + if (ext4_inode_buffered_iomap(inode)) + wait_event(EXT4_I(inode)->i_ordered_wq, + READ_ONCE(EXT4_I(inode)->i_ordered_len) =3D=3D 0); + truncate_pagecache(inode, start); =20 credits =3D ext4_chunk_trans_extent(inode, 0); @@ -5671,6 +5688,7 @@ static int ext4_insert_range(struct file *file, loff_= t offset, loff_t len) ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_FALLOC_RANGE, handle); =20 /* Expand file to avoid data loss if there is error while shifting */ + WARN_ON_ONCE(READ_ONCE(EXT4_I(inode)->i_ordered_len) !=3D 0); inode->i_size +=3D len; EXT4_I(inode)->i_disksize +=3D len; ret =3D ext4_mark_inode_dirty(handle, inode); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 23efb44f0c27..e47b504e85c9 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4899,7 +4899,9 @@ int ext4_block_zero_eof(struct inode *inode, loff_t f= rom, loff_t end) * i_size by the end_io handler once the ongoing I/O * completes. * - * - TODO: handle insert range and collapse range. + * - Insert range and collapse range operations: + * Wait synchronously for the relevant I/O to complete + * before updating i_disksize. */ } else if (ext4_inode_buffered_iomap(inode)) { err =3D ext4_iomap_submit_zero_block(inode, from, end); --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 F1317386566; Mon, 11 May 2026 07:28:31 +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=1778484514; cv=none; b=C/oBCX/5rVz1LshsiUBG7PjEw9mS9wd3Qlj2uGs95sgq+uDTyxYrKDZfRtrqLWogYQRYwehWrH2ggVUgnFXxLRFDogMzL0YcpuZ10zm2NViYutm+5/zwU7HqIYZF3Y0tvd0R4zpID6AcKiNzoiWUB54/QELMt9cpdyZWv9sVcUg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484514; c=relaxed/simple; bh=DV6BkAGGa01aQQRJVdiy0dut1brwqYobljVY8Z8rfhQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jR/FFRkHPq4V3QQtru/dW5HvgFoTWTJOEzYKXTPchFY42vBmGsp/2Ok89HUhX/scnZNQmDI4/+UxHijSedGHLbAdoFq7d+6JZDQ1oGVfLJVHDl+EiKMyGF489YPPl/Y5iNXSTPCefcCrhSMGXaR5bhVZoJumTG/3iIzkKT+8z/A= 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.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX55hw4zKHMg1; Mon, 11 May 2026 15:27:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 51EF54056D; Mon, 11 May 2026 15:28:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S25; Mon, 11 May 2026 15:28:24 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 21/23] ext4: add tracepoints for ordered I/O in the iomap buffered I/O path Date: Mon, 11 May 2026 15:23:41 +0800 Message-ID: <20260511072344.191271-22-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S25 X-Coremail-Antispam: 1UD129KBjvJXoW3Ww1xuryrGr45WFW8KFyxAFb_yoWxZFyrpF yDCryrGw48Zrn09w4xXw4Iqr4Yva1rua18try3WFyDZ3yxAr92kF47KF98ZFy8tr4qyryI gF4DArWkKw1DXrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW5JVW7JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi To facilitate the tracing of ordered I/Os in the iomap buffered I/O path, add tracepoints to track the ordered I/O flow: - ext4_iomap_ordered_submit: trace when ordered I/O is being submitted; - ext4_iomap_ordered_complete: trace when ordered I/O completes; - ext4_iomap_disksize_update: trace when i_disksize is updated, either when appending I/O or when an ordered I/O completes; - ext4_block_zero_eof - trace zero EOF partial block. Signed-off-by: Zhang Yi --- fs/ext4/inode.c | 4 ++ fs/ext4/page-io.c | 9 ++++ include/trace/events/ext4.h | 97 +++++++++++++++++++++++++++++++++++++ 3 files changed, 110 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index e47b504e85c9..cf83b4e619e0 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4376,6 +4376,9 @@ static int ext4_iomap_writeback_submit(struct iomap_w= ritepage_ctx *wpc, ioend->io_offset + ioend->io_size); =20 if (start <=3D order_lblk && end >=3D order_lblk + order_len) { + trace_ext4_iomap_ordered_submit(ioend->io_inode, + ioend->io_offset, ioend->io_size, + order_lblk, order_len); ioend->io_bio.bi_end_io =3D ext4_iomap_end_bio; ioend->io_private =3D (void *)EXT4_IOMAP_IOEND_ORDER_IO; ioend->io_flags |=3D IOMAP_IOEND_BOUNDARY; @@ -4910,6 +4913,7 @@ int ext4_block_zero_eof(struct inode *inode, loff_t f= rom, loff_t end) } } =20 + trace_ext4_block_zero_eof(inode, from, length, did_zero, zero_written); return 0; } =20 diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c index 2ad9f900c9f3..b5b32dc388be 100644 --- a/fs/ext4/page-io.c +++ b/fs/ext4/page-io.c @@ -31,6 +31,8 @@ #include "xattr.h" #include "acl.h" =20 +#include + static struct kmem_cache *io_end_cachep; static struct kmem_cache *io_end_vec_cachep; =20 @@ -682,6 +684,9 @@ static int ext4_iomap_wb_update_disksize(handle_t *hand= le, struct inode *inode, * not yet on disk, but stale data will never be exposed. */ new_disksize =3D is_ordered ? i_size : min(end, i_size); + trace_ext4_iomap_disksize_update(inode, end, i_size, ei->i_disksize, + new_disksize, is_ordered); + if (new_disksize > ei->i_disksize) ei->i_disksize =3D new_disksize; up_write(&ei->i_data_sem); @@ -784,6 +789,10 @@ void ext4_iomap_end_bio(struct bio *bio) * the inode i_disksize. */ if (io_mode =3D=3D EXT4_IOMAP_IOEND_ORDER_IO) { + trace_ext4_iomap_ordered_complete(inode, ioend->io_offset, + ioend->io_size, READ_ONCE(ei->i_ordered_lblk), + READ_ONCE(ei->i_ordered_len)); + /* * Pairs with wait_event() in ext4_iomap_wb_ordered_wait(). * Ensure i_ordered_len =3D 0 is visible before waking up diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h index ebafa06cd191..423aec6d09d1 100644 --- a/include/trace/events/ext4.h +++ b/include/trace/events/ext4.h @@ -3141,6 +3141,103 @@ DEFINE_SET_IOMAP_EVENT(ext4_iomap_buffered_write_be= gin); DEFINE_SET_IOMAP_EVENT(ext4_iomap_map_writeback_range); DEFINE_SET_IOMAP_EVENT(ext4_iomap_zero_begin); =20 +/* Ordered I/O tracepoints for iomap buffered I/O path */ +DECLARE_EVENT_CLASS(ext4_iomap_ordered_io, + TP_PROTO(struct inode *inode, loff_t io_offset, size_t io_size, + ext4_lblk_t i_ordered_lblk, unsigned int i_ordered_len), + TP_ARGS(inode, io_offset, io_size, i_ordered_lblk, i_ordered_len), + TP_STRUCT__entry( + __field(dev_t, dev) + __field(u64, ino) + __field(loff_t, io_offset) + __field(size_t, io_size) + __field(ext4_lblk_t, i_ordered_lblk) + __field(unsigned int, i_ordered_len) + ), + TP_fast_assign( + __entry->dev =3D inode->i_sb->s_dev; + __entry->ino =3D inode->i_ino; + __entry->io_offset =3D io_offset; + __entry->io_size =3D io_size; + __entry->i_ordered_lblk =3D i_ordered_lblk; + __entry->i_ordered_len =3D i_ordered_len; + ), + TP_printk("dev %d:%d ino %llu io_offset %lld io_size %zu i_ordered_lblk %= u i_ordered_len %u", + MAJOR(__entry->dev), MINOR(__entry->dev), + __entry->ino, __entry->io_offset, __entry->io_size, + __entry->i_ordered_lblk, __entry->i_ordered_len) +); + +DEFINE_EVENT(ext4_iomap_ordered_io, ext4_iomap_ordered_submit, + TP_PROTO(struct inode *inode, loff_t io_offset, size_t io_size, + ext4_lblk_t i_ordered_lblk, unsigned int i_ordered_len), + TP_ARGS(inode, io_offset, io_size, i_ordered_lblk, i_ordered_len) +); + +DEFINE_EVENT(ext4_iomap_ordered_io, ext4_iomap_ordered_complete, + TP_PROTO(struct inode *inode, loff_t io_offset, size_t io_size, + ext4_lblk_t i_ordered_lblk, unsigned int i_ordered_len), + TP_ARGS(inode, io_offset, io_size, i_ordered_lblk, i_ordered_len) +); + + +/* i_disksize update tracepoint */ +TRACE_EVENT(ext4_iomap_disksize_update, + TP_PROTO(struct inode *inode, loff_t end, loff_t i_size, + loff_t i_disksize, loff_t new_disksize, bool is_ordered), + TP_ARGS(inode, end, i_size, i_disksize, new_disksize, is_ordered), + TP_STRUCT__entry( + __field(dev_t, dev) + __field(u64, ino) + __field(loff_t, end) + __field(loff_t, i_size) + __field(loff_t, i_disksize) + __field(loff_t, new_disksize) + __field(bool, is_ordered) + ), + TP_fast_assign( + __entry->dev =3D inode->i_sb->s_dev; + __entry->ino =3D inode->i_ino; + __entry->end =3D end; + __entry->i_size =3D i_size; + __entry->i_disksize =3D i_disksize; + __entry->new_disksize =3D new_disksize; + __entry->is_ordered =3D is_ordered; + ), + TP_printk("dev %d:%d ino %llu end %lld i_size %lld i_disksize %lld new_di= sksize %lld is_ordered %d", + MAJOR(__entry->dev), MINOR(__entry->dev), + __entry->ino, __entry->end, __entry->i_size, + __entry->i_disksize, __entry->new_disksize, + __entry->is_ordered) +); + +/* Block zero EOF tracepoint */ +TRACE_EVENT(ext4_block_zero_eof, + TP_PROTO(struct inode *inode, loff_t from, loff_t length, + bool did_zero, bool zero_written), + TP_ARGS(inode, from, length, did_zero, zero_written), + TP_STRUCT__entry( + __field(dev_t, dev) + __field(u64, ino) + __field(loff_t, from) + __field(loff_t, length) + __field(bool, did_zero) + __field(bool, zero_written) + ), + TP_fast_assign( + __entry->dev =3D inode->i_sb->s_dev; + __entry->ino =3D inode->i_ino; + __entry->from =3D from; + __entry->length =3D length; + __entry->did_zero =3D did_zero; + __entry->zero_written =3D zero_written; + ), + TP_printk("dev %d:%d ino %llu zero EOF from %lld length %lld did_zero %d = zero_written %d", + MAJOR(__entry->dev), MINOR(__entry->dev), + __entry->ino, __entry->from, __entry->length, + __entry->did_zero, __entry->zero_written) +); + #endif /* _TRACE_EXT4_H */ =20 /* This part must be outside protection */ --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 2E394388390; Mon, 11 May 2026 07:28:34 +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=1778484519; cv=none; b=jvcDgtcGUi1nghcbDOAPnzA9wJYVR251zUbH6hkFeFXXMp70Y8F8o6a7IaWbVvysHK+RzLQV3MhlVuBB/dI2/0JPyCcAQiOb3YY6oMaTjBjZMNqY462Uy2TytZA+xd5BQ/SqtJt4dbQjQPjB+C/VBIostuA44tVVWN7FS8hjFVU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484519; c=relaxed/simple; bh=PMEVtIA0RqSxL0YdtSsnwtF2sqk55TO7wCLofEYzyuw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ibJGreS7aBXOOBP6G2mg4Z6RK3sE8R7fdqP7ph0DNdsz3eueZXlJhMDHE2soFKd6A5eal8ZKhJCV5TIE4r6Ny77MrR4acQJHxuX+XCvH3+B4Oz3pNAX3p6bQXKGp5Lw9YvX5MiZoWlIoDB52k6OqattuPj/1JS4hpddon1qCGJo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=none 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=none smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX56WMszKHMgD; Mon, 11 May 2026 15:27:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 6FBCB40590; Mon, 11 May 2026 15:28:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S26; Mon, 11 May 2026 15:28:24 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 22/23] ext4: partially enable iomap for the buffered I/O path of regular files Date: Mon, 11 May 2026 15:23:42 +0800 Message-ID: <20260511072344.191271-23-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S26 X-Coremail-Antispam: 1UD129KBjvJXoWxtF4UKF13Cr43KF1kJF1UZFb_yoWfZry3pr ZxK34rGrn0qryv9w4Iqr4UXr1Yv3WxG3yUGrZ3ur1kAa98Gw1IqFyjyF1YvF15JrWfWw12 qF48tw1UuwsFkrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW5JVW7JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Introduce ext4_enable_buffered_iomap() to determine whether a regular file inode should use the iomap buffered I/O path. We now support the default filesystem features, mount options, and the bigalloc feature. However, inline data, fsverity, fscrypt, indirect inode type, and data=3Djournal mode are not fully supported. The decision is made at inode initialization time in __ext4_new_inode() and __ext4_iget() by setting the EXT4_STATE_BUFFERED_IOMAP state flag. If any of these unsupported features are met, the inode silently falls back to the traditional buffer_head path. Switching the buffered I/O path on an active inode is not supported, with the exception of changing a per-inode journal flag. For features like encryption, verity, and inline data that can be dynamically enabled at the superblock level, checking the global feature flag avoids the complexity of toggling the path on individual inodes. Additionally: - Extend ext4_inode_journal_mode() to force ordered mode for inodes using the iomap path under a data=3Djournal mount. For the global data journal mode (EXT4_MOUNT_JOURNAL_DATA), dynamic enablement is deferred until the next inode re-initialization. For the per-inode data journal mode (EXT4_INODE_JOURNAL_DATA), dynamic changes take effect immediately, as it is safe to switch address_space operations and drop all page cache under i_rwsem and filemap_invalidate_lock. - Add WARN_ON_ONCE() guards in _ext4_get_block() and ext4_do_writepages() to catch inodes using the iomap path from accidentally entering the legacy buffer_head writeback path. - Reject extent-to-indirect migration via ext4_ind_migrate() for inodes on the iomap path. Signed-off-by: Zhang Yi --- fs/ext4/ext4.h | 1 + fs/ext4/ext4_jbd2.c | 8 +++-- fs/ext4/ialloc.c | 1 + fs/ext4/inode.c | 77 +++++++++++++++++++++++++++++++++++++++++++-- fs/ext4/migrate.c | 2 ++ 5 files changed, 85 insertions(+), 4 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 0a3bb44f1e6e..afba952abd28 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -3068,6 +3068,7 @@ int ext4_walk_page_buffers(handle_t *handle, int do_journal_get_write_access(handle_t *handle, struct inode *inode, struct buffer_head *bh); void ext4_set_inode_mapping_order(struct inode *inode); +void ext4_enable_buffered_iomap(struct inode *inode); int ext4_nonda_switch(struct super_block *sb); #define FALL_BACK_TO_NONDELALLOC 1 #define CONVERT_INLINE_DATA 2 diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c index 9a8c225f2753..4534cf6f5e76 100644 --- a/fs/ext4/ext4_jbd2.c +++ b/fs/ext4/ext4_jbd2.c @@ -17,8 +17,12 @@ int ext4_inode_journal_mode(struct inode *inode) test_opt(inode->i_sb, DATA_FLAGS) =3D=3D EXT4_MOUNT_JOURNAL_DATA || (ext4_test_inode_flag(inode, EXT4_INODE_JOURNAL_DATA) && !test_opt(inode->i_sb, DELALLOC))) { - /* We do not support data journalling for encrypted data */ - if (S_ISREG(inode->i_mode) && IS_ENCRYPTED(inode)) + /* + * We do not support data journalling for encrypted data + * and buffered IOMAP path. + */ + if (S_ISREG(inode->i_mode) && + (IS_ENCRYPTED(inode) || ext4_inode_buffered_iomap(inode))) return EXT4_INODE_ORDERED_DATA_MODE; /* ordered */ return EXT4_INODE_JOURNAL_DATA_MODE; /* journal data */ } diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c index 3fd8f0099852..ea64b9e9e382 100644 --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -1340,6 +1340,7 @@ struct inode *__ext4_new_inode(struct mnt_idmap *idma= p, } } =20 + ext4_enable_buffered_iomap(inode); ext4_set_inode_mapping_order(inode); =20 ext4_update_inode_fsync_trans(handle, inode, 1); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index cf83b4e619e0..0407e7b54dcd 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -918,6 +918,9 @@ static int _ext4_get_block(struct inode *inode, sector_= t iblock, =20 if (ext4_has_inline_data(inode)) return -ERANGE; + /* inode using the iomap buffered I/O path should not go here. */ + if (WARN_ON_ONCE(ext4_inode_buffered_iomap(inode))) + return -EINVAL; =20 map.m_lblk =3D iblock; map.m_len =3D bh->b_size >> inode->i_blkbits; @@ -2797,6 +2800,12 @@ static int ext4_do_writepages(struct mpage_da_data *= mpd) if (!mapping->nrpages || !mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) goto out_writepages; =20 + /* inode using the iomap buffered I/O path should not go here. */ + if (WARN_ON_ONCE(ext4_inode_buffered_iomap(inode))) { + ret =3D -EINVAL; + goto out_writepages; + } + /* * If the filesystem has aborted, it is read-only, so return * right away instead of dumping stack traces later on that @@ -3929,6 +3938,9 @@ static int ext4_iomap_map_blocks(struct inode *inode,= loff_t offset, { u8 blkbits =3D inode->i_blkbits; =20 + /* inode using the buffer_head buffered I/O path should not go here. */ + if (WARN_ON_ONCE(!ext4_inode_buffered_iomap(inode))) + return -EINVAL; if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK) return -EINVAL; =20 @@ -4406,6 +4418,10 @@ static int ext4_iomap_writepages(struct address_spac= e *mapping, .ops =3D &ext4_writeback_ops, }; =20 + /* inode using the buffer_head buffered I/O path should not go here. */ + if (WARN_ON_ONCE(!ext4_inode_buffered_iomap(inode))) + return -EINVAL; + ret =3D ext4_emergency_state(sb); if (unlikely(ret)) return ret; @@ -5864,6 +5880,59 @@ static int check_igot_inode(struct inode *inode, ext= 4_iget_flags flags, return -EFSCORRUPTED; } =20 +/* + * Determine whether an inode should use the iomap buffered I/O path. + * EXT4_STATE_BUFFERED_IOMAP is generally set at inode initialization + * time. Online switching of the buffered I/O path on an active inode is + * NOT supported, with the exception of changing a per-inode journal + * flag. + * + * For features like inline data, fsverity, and encryption that can be + * dynamically enabled or disabled, we check the superblock-level + * feature flags. If any of these is globally enabled, no inode is + * allowed into the iomap buffered I/O path. This avoids the complexity + * of dynamic toggling. + * + * For the global data journal mode (EXT4_MOUNT_JOURNAL_DATA), dynamic + * change through remount is deferred. It will only become available + * after the inode is re-initialized (i.e., after the last reference + * drops and the inode is re-read from disk with the journal flag + * cleared). + * + * For the per-inode data journal mode (EXT4_INODE_JOURNAL_DATA), + * dynamic changes take effect immediately. This is safe because + * address_space operations can be switched and all page cache can be + * dropped under i_rwsem and filemap_invalidate_lock. + * + * For extent-to-indirect block migration (via EXT4_IOC_SETFLAGS + * clearing EXT4_EXTENTS_FL), this operation is directly rejected for + * inodes using the iomap path. + */ +void ext4_enable_buffered_iomap(struct inode *inode) +{ + struct super_block *sb =3D inode->i_sb; + + if (!S_ISREG(inode->i_mode)) + return; + if (ext4_test_inode_flag(inode, EXT4_INODE_EA_INODE)) + return; + + /* Unsupported Features */ + if (ext4_has_feature_inline_data(sb)) + return; + if (ext4_has_feature_verity(sb)) + return; + if (ext4_has_feature_encrypt(sb)) + return; + if (test_opt(sb, DATA_FLAGS) =3D=3D EXT4_MOUNT_JOURNAL_DATA || + ext4_test_inode_flag(inode, EXT4_INODE_JOURNAL_DATA)) + return; + if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) + return; + + ext4_set_inode_state(inode, EXT4_STATE_BUFFERED_IOMAP); +} + void ext4_set_inode_mapping_order(struct inode *inode) { struct super_block *sb =3D inode->i_sb; @@ -6149,6 +6218,8 @@ struct inode *__ext4_iget(struct super_block *sb, uns= igned long ino, if (ret) goto bad_inode; =20 + ext4_enable_buffered_iomap(inode); + if (S_ISREG(inode->i_mode)) { inode->i_op =3D &ext4_file_inode_operations; inode->i_fop =3D &ext4_file_operations; @@ -7326,9 +7397,10 @@ int ext4_change_inode_journal_flag(struct inode *ino= de, int val) * the inode's in-core data-journaling state flag now. */ =20 - if (val) + if (val) { ext4_set_inode_flag(inode, EXT4_INODE_JOURNAL_DATA); - else { + ext4_clear_inode_state(inode, EXT4_STATE_BUFFERED_IOMAP); + } else { err =3D jbd2_journal_flush(journal, 0); if (err < 0) { jbd2_journal_unlock_updates(journal); @@ -7337,6 +7409,7 @@ int ext4_change_inode_journal_flag(struct inode *inod= e, int val) return err; } ext4_clear_inode_flag(inode, EXT4_INODE_JOURNAL_DATA); + ext4_enable_buffered_iomap(inode); } ext4_set_aops(inode); ext4_set_inode_mapping_order(inode); diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c index 477d43d7e294..3b49ecf427ae 100644 --- a/fs/ext4/migrate.c +++ b/fs/ext4/migrate.c @@ -620,6 +620,8 @@ int ext4_ind_migrate(struct inode *inode) =20 if (ext4_has_feature_bigalloc(inode->i_sb)) return -EOPNOTSUPP; + if (ext4_inode_buffered_iomap(inode)) + return -EOPNOTSUPP; =20 /* * In order to get correct extent info, force all delayed allocation --=20 2.52.0 From nobody Sat Jun 13 03:31:33 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [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 36D1B382F12; Mon, 11 May 2026 07:28:33 +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=1778484515; cv=none; b=p2igSRejRPlTO1mnebC4oTRdogL2HZwcPuYbe8Up5q6IlzFyVak1QeQ1crDn1/l4U193LLr2fxdFutUfNem3FsIdIYEtqanm8YZvF1ViIj7Gm0pMSL8hIaUhaPNxFLVQABs6m/CPshMcHcjZt5b9naGNeKZfEuCZTSJkiEz2peo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778484515; c=relaxed/simple; bh=sC2PMkkRrNq9n4qZSxY2/rgPnKy2JdKz6pFNsx2pU7A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Muhq43sVjHqznl90P5AT7f08yZI2bfZWUMVZAPnzPclzyPIXvrMDIrVo+Lg+FqOjPlSKNbZbF49NJtIw5VH66EzId+c3Tg61iPYqagMA0vnvPnnxvWiA/hWhvljmB+YiouZpPMFb7m7H5PhdESFS+BebaOtaVs8NS++TLTlWUnI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=none 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=none smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gDWX572VBzKHMgF; Mon, 11 May 2026 15:27:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 7F6C040561; Mon, 11 May 2026 15:28:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgD3v1sKhQFqAy6MBw--.28537S27; Mon, 11 May 2026 15:28:24 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org, hch@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 23/23] ext4: introduce a mount option for iomap buffered I/O path Date: Mon, 11 May 2026 15:23:43 +0800 Message-ID: <20260511072344.191271-24-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511072344.191271-1-yi.zhang@huaweicloud.com> References: <20260511072344.191271-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: gCh0CgD3v1sKhQFqAy6MBw--.28537S27 X-Coremail-Antispam: 1UD129KBjvJXoWxWr47Kr15Gr1xZry3ZFy7KFg_yoWrGr1xpr WYgFyrGr1kXryF9w4xuFs5Xr1Yy3ZIka1UCrWFgr47Ga9rAryIqFyfKF15AFW2grW8X34I qF1rWw17Ga13CrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW5JVW7JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Since the iomap buffered I/O path does not yet support all existing ext4 features, it cannot be enabled by default. Introduce the 'buffered_iomap' and 'nobuffered_iomap' mount options to explicitly enable or disable the iomap buffered I/O path for regular files. Toggling this option via remount is allowed. The change of I/O path will not take effect immediately. It will be deferred. The new setting will only take effect after the inode is re-initialized (i.e., after the last reference is dropped and the inode is re-read from disk). Signed-off-by: Zhang Yi --- fs/ext4/ext4.h | 1 + fs/ext4/inode.c | 6 ++++++ fs/ext4/super.c | 7 +++++++ 3 files changed, 14 insertions(+) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index afba952abd28..33da8c1915a7 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1290,6 +1290,7 @@ struct ext4_inode_info { * scanning in mballoc */ #define EXT4_MOUNT2_ABORT 0x00000100 /* Abort filesystem */ +#define EXT4_MOUNT2_BUFFERED_IOMAP 0x00000200 /* Use iomap for buffered I/= O */ =20 #define clear_opt(sb, opt) EXT4_SB(sb)->s_mount_opt &=3D \ ~EXT4_MOUNT_##opt diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 0407e7b54dcd..1432ef29748b 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5907,11 +5907,17 @@ static int check_igot_inode(struct inode *inode, ex= t4_iget_flags flags, * For extent-to-indirect block migration (via EXT4_IOC_SETFLAGS * clearing EXT4_EXTENTS_FL), this operation is directly rejected for * inodes using the iomap path. + * + * When remounting to toggle the buffered_iomap mount option, the change + * of I/O path is deferred as well, it will be available after the inode + * is re-initialized. */ void ext4_enable_buffered_iomap(struct inode *inode) { struct super_block *sb =3D inode->i_sb; =20 + if (!test_opt2(sb, BUFFERED_IOMAP)) + return; if (!S_ISREG(inode->i_mode)) return; if (ext4_test_inode_flag(inode, EXT4_INODE_EA_INODE)) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 9c0a00e716f3..2fc07739c9e8 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1733,6 +1733,7 @@ enum { Opt_discard, Opt_nodiscard, Opt_init_itable, Opt_noinit_itable, Opt_max_dir_size_kb, Opt_nojournal_checksum, Opt_nombcache, Opt_no_prefetch_block_bitmaps, Opt_mb_optimize_scan, + Opt_buffered_iomap, Opt_nobuffered_iomap, Opt_errors, Opt_data, Opt_data_err, Opt_jqfmt, Opt_dax_type, #ifdef CONFIG_EXT4_DEBUG Opt_fc_debug_max_replay, Opt_fc_debug_force @@ -1871,6 +1872,8 @@ static const struct fs_parameter_spec ext4_param_spec= s[] =3D { fsparam_flag ("no_prefetch_block_bitmaps", Opt_no_prefetch_block_bitmaps), fsparam_s32 ("mb_optimize_scan", Opt_mb_optimize_scan), + fsparam_flag ("buffered_iomap", Opt_buffered_iomap), + fsparam_flag ("nobuffered_iomap", Opt_nobuffered_iomap), fsparam_string ("check", Opt_removed), /* mount option from ext2/3 */ fsparam_flag ("nocheck", Opt_removed), /* mount option from ext2/3 */ fsparam_flag ("reservation", Opt_removed), /* mount option from ext2/3 */ @@ -1964,6 +1967,10 @@ static const struct mount_opts { {Opt_nombcache, EXT4_MOUNT_NO_MBCACHE, MOPT_SET}, {Opt_no_prefetch_block_bitmaps, EXT4_MOUNT_NO_PREFETCH_BLOCK_BITMAPS, MOPT_SET}, + {Opt_buffered_iomap, EXT4_MOUNT2_BUFFERED_IOMAP, + MOPT_SET | MOPT_2 | MOPT_EXT4_ONLY}, + {Opt_nobuffered_iomap, EXT4_MOUNT2_BUFFERED_IOMAP, + MOPT_CLEAR | MOPT_2 | MOPT_EXT4_ONLY}, #ifdef CONFIG_EXT4_DEBUG {Opt_fc_debug_force, EXT4_MOUNT2_JOURNAL_FAST_COMMIT, MOPT_SET | MOPT_2 | MOPT_EXT4_ONLY}, --=20 2.52.0