From nobody Mon Dec 1 22:36:27 2025 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 A641E823DD; Sat, 29 Nov 2025 10:35:32 +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=1764412535; cv=none; b=UVp4KM8gyh8jSV5O8gO0XGFnbZO3sjcHuA1MnZxAgYq28MJjJ05CTUlfjBe/+M4c0me0lb4UtjZDxnTqbfDU9WwnIXTvHJGOiOnUYOgFQ4000ROawSLbE9gOslHfAM9oO1YvMpycANJUsmRYaZqp/jT8KsHlt21kvf0F6yTUuAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412535; c=relaxed/simple; bh=38LyJzVCn5FfrZVCrtCdq5bKp6vzZfSy+AkV5a5Gmec=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=giVEWVMryUUFA5nLBzvhutNHRbi6XxiPMLORHnbELshPSYxBIWy/fHmZyYdcazYjSrTr01iI6GzuNqG8Mi0b8aLQGwpV+bP1y/LhbXiWUIPryhK+nVLbkc6Dzl5SxE/mxSBsuEhfv6KDorVLd6APXhY0JJbHtREm5mLk2xL4m1Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dJRP53bv2zYQtp4; Sat, 29 Nov 2025 18:34:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 47BE41A14FE; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S5; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 01/14] ext4: subdivide EXT4_EXT_DATA_VALID1 Date: Sat, 29 Nov 2025 18:32:33 +0800 Message-ID: <20251129103247.686136-2-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S5 X-Coremail-Antispam: 1UD129KBjvJXoWxAr15KryxZr18tw4xGF15Arb_yoW5try5pF 4a9ayUGr1Dt34F934xtF4Dur45Gw1xGw1DAr9xWw15tay3Ga4aqF1fKw4aqas8Krs5ZrWU ZrWFyr48Cas8Ca7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JUfKs8UUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When splitting an extent, if the EXT4_GET_BLOCKS_CONVERT flag is set and it is necessary to split the target extent in the middle, ext4_split_extent() first handles splitting the latter half of the extent and passes the EXT4_EXT_DATA_VALID1 flag. This flag implies that all blocks before the split point contain valid data; however, this assumption is incorrect. Therefore, subdivid EXT4_EXT_DATA_VALID1 into EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_DATA_PARTIAL_VALID1, which indicate that the first half of the extent is either entirely valid or only partially valid, respectively. These two flags cannot be set simultaneously. This patch does not use EXT4_EXT_DATA_PARTIAL_VALID1, it only replaces EXT4_EXT_DATA_VALID1 with EXT4_EXT_DATA_ENTIRE_VALID1 at the location where it is set, no logical changes. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org --- fs/ext4/extents.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 2cf5759ba689..8d5ca450aa5d 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -43,8 +43,13 @@ #define EXT4_EXT_MARK_UNWRIT1 0x2 /* mark first half unwritten */ #define EXT4_EXT_MARK_UNWRIT2 0x4 /* mark second half unwritten */ =20 -#define EXT4_EXT_DATA_VALID1 0x8 /* first half contains valid data */ -#define EXT4_EXT_DATA_VALID2 0x10 /* second half contains valid data */ +/* first half contains valid data */ +#define EXT4_EXT_DATA_ENTIRE_VALID1 0x8 /* has entirely valid data */ +#define EXT4_EXT_DATA_PARTIAL_VALID1 0x10 /* has partially valid data */ +#define EXT4_EXT_DATA_VALID1 (EXT4_EXT_DATA_ENTIRE_VALID1 | \ + EXT4_EXT_DATA_PARTIAL_VALID1) + +#define EXT4_EXT_DATA_VALID2 0x20 /* second half contains valid data */ =20 static __le32 ext4_extent_block_csum(struct inode *inode, struct ext4_extent_header *eh) @@ -3190,8 +3195,9 @@ static struct ext4_ext_path *ext4_split_extent_at(han= dle_t *handle, unsigned int ee_len, depth; int err =3D 0; =20 - BUG_ON((split_flag & (EXT4_EXT_DATA_VALID1 | EXT4_EXT_DATA_VALID2)) =3D= =3D - (EXT4_EXT_DATA_VALID1 | EXT4_EXT_DATA_VALID2)); + BUG_ON((split_flag & EXT4_EXT_DATA_VALID1) =3D=3D EXT4_EXT_DATA_VALID1); + BUG_ON((split_flag & EXT4_EXT_DATA_VALID1) && + (split_flag & EXT4_EXT_DATA_VALID2)); =20 ext_debug(inode, "logical block %llu\n", (unsigned long long)split); =20 @@ -3373,7 +3379,7 @@ static struct ext4_ext_path *ext4_split_extent(handle= _t *handle, split_flag1 |=3D EXT4_EXT_MARK_UNWRIT1 | EXT4_EXT_MARK_UNWRIT2; if (split_flag & EXT4_EXT_DATA_VALID2) - split_flag1 |=3D EXT4_EXT_DATA_VALID1; + split_flag1 |=3D EXT4_EXT_DATA_ENTIRE_VALID1; path =3D ext4_split_extent_at(handle, inode, path, map->m_lblk + map->m_len, split_flag1, flags1); if (IS_ERR(path)) @@ -3728,7 +3734,7 @@ static struct ext4_ext_path *ext4_split_convert_exten= ts(handle_t *handle, =20 /* Convert to unwritten */ if (flags & EXT4_GET_BLOCKS_CONVERT_UNWRITTEN) { - split_flag |=3D EXT4_EXT_DATA_VALID1; + split_flag |=3D EXT4_EXT_DATA_ENTIRE_VALID1; /* Convert to initialized */ } else if (flags & EXT4_GET_BLOCKS_CONVERT) { /* --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 A653E268688; Sat, 29 Nov 2025 10:35:32 +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=1764412536; cv=none; b=OGv5xoe7smlJ7n3yrwAbNzol+OoNuB1886a6dMP4laYx1vNhopQC6ZGJeB8tR4olfmQ3npadp+RbXb2kjtFKLhj72WRNQvmVqTRLCEuvY2EkmE/mwH2YQPlAXFam9/RLUNxi1nw1LLG+EeFeAnd9QZbwPDLB4SpAIXbqdzgxwmI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412536; c=relaxed/simple; bh=ReiZJd/VgtGEXMF52xOmlgqyWePqCB+DaTHcNzLl0Ak=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QbIayuSYaxVfY2Wifd7hIAHJxsEmTptfwp0eBEVTA8hAzVWskLUf9uaiF/d7EZb1noxHYP9pNddXYj2lxdQOHVrMuYHaCrznH2SRVhGJKIUoGmZqzvo1LsjRtOfDXv6DfOshb0uhwuf7sBXS4Vpr1luVRox3OiYdBvyWG7CgNlU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dJRP54GMkzYQtnq; Sat, 29 Nov 2025 18:34:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 5CC291A0359; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S6; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 02/14] ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 Date: Sat, 29 Nov 2025 18:32:34 +0800 Message-ID: <20251129103247.686136-3-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S6 X-Coremail-Antispam: 1UD129KBjvJXoWxGF1DGryxXr4Uur1UZF43ZFb_yoW5ArWDpF 4S9a4UGr4DG340934xJF1kZr1qk3W8WrW7Cry5Grn8K3WDKryagFs3Ka1YqFyFgr48ZFy5 Ar4FyrW5G3Z8JaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JUADGOUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org --- fs/ext4/extents.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 8d5ca450aa5d..1fee84ea20af 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3310,6 +3310,15 @@ static struct ext4_ext_path *ext4_split_extent_at(ha= ndle_t *handle, } =20 if (!err) { + /* + * The first half contains partially valid data, the + * splitting of this extent has not been completed, fix + * extent length and ext4_split_extent() split will the + * first half again. + */ + if (split_flag & EXT4_EXT_DATA_PARTIAL_VALID1) + goto fix_extent_len; + /* update the extent length and mark as initialized */ ex->ee_len =3D cpu_to_le16(ee_len); ext4_ext_try_to_merge(handle, inode, path, ex); @@ -3379,7 +3388,9 @@ static struct ext4_ext_path *ext4_split_extent(handle= _t *handle, split_flag1 |=3D EXT4_EXT_MARK_UNWRIT1 | EXT4_EXT_MARK_UNWRIT2; if (split_flag & EXT4_EXT_DATA_VALID2) - split_flag1 |=3D EXT4_EXT_DATA_ENTIRE_VALID1; + split_flag1 |=3D map->m_lblk > ee_block ? + EXT4_EXT_DATA_PARTIAL_VALID1 : + EXT4_EXT_DATA_ENTIRE_VALID1; path =3D ext4_split_extent_at(handle, inode, path, map->m_lblk + map->m_len, split_flag1, flags1); if (IS_ERR(path)) --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 E7F1E288C3F; Sat, 29 Nov 2025 10:35:38 +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=1764412541; cv=none; b=cDI2fjrNdb7eUa5uKACVrOuv4jyMjO5HKLRwB/qO6DKRqlmuPAKN31Sic/3mXoBI+Znd7cqK7MLWbFaOA60aCXY5jdsLuEc2YvvD6rnQukrodXkDySQc12EkLGxo0LYVF9RTuNHf0jU3SR8sbYaVlJmjxe0pyLWgRtp3QHpCFNg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412541; c=relaxed/simple; bh=weFdg7qQPlX2DfZMTJVdYP+PXjyYzUtnLktj89FdhpQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=J9iaBv+PyZaK5RD2Ukv3qb1uW/5dGjZhhHfEwozt/kdye0OA/iJVqxI3aAMIYcDfzMU2OAnSWq6cqdCHwy6kxad0LbnvUWpERxsrXc9J/8JUvGD3cSFyForipZ+dxW+p2YT0q3HuU46SSeAp11bntg2Xo3okIttZq3jbvlc6XYQ= 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.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPM2BgPzKHMQ4; Sat, 29 Nov 2025 18:34:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 74C041A0C32; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S7; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 03/14] ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O Date: Sat, 29 Nov 2025 18:32:35 +0800 Message-ID: <20251129103247.686136-4-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S7 X-Coremail-Antispam: 1UD129KBjvJXoWxGF1fJFyftw17XF17Kr4xXrb_yoWrXFyDpF 4I9F18Jr4kt34ru34xJ3Wqqr1jgw18GrsrAryjg3yjkayDtrySgF1rKa4FgFyFgr4rZayY yr4FvFyjkas8G37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JUCg4hUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency. Fixes: b8a8684502a0 ("ext4: Introduce FALLOC_FL_ZERO_RANGE flag for falloca= te") Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org --- fs/ext4/extents.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 1fee84ea20af..91b56de60c90 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3746,15 +3746,19 @@ static struct ext4_ext_path *ext4_split_convert_ext= ents(handle_t *handle, /* Convert to unwritten */ if (flags & EXT4_GET_BLOCKS_CONVERT_UNWRITTEN) { split_flag |=3D EXT4_EXT_DATA_ENTIRE_VALID1; - /* Convert to initialized */ - } else if (flags & EXT4_GET_BLOCKS_CONVERT) { + /* Split the existing unwritten extent */ + } else if (flags & (EXT4_GET_BLOCKS_UNWRIT_EXT | + EXT4_GET_BLOCKS_CONVERT)) { /* * It is safe to convert extent to initialized via explicit * zeroout only if extent is fully inside i_size or new_size. */ split_flag |=3D ee_block + ee_len <=3D eof_block ? EXT4_EXT_MAY_ZEROOUT : 0; - split_flag |=3D (EXT4_EXT_MARK_UNWRIT2 | EXT4_EXT_DATA_VALID2); + split_flag |=3D EXT4_EXT_MARK_UNWRIT2; + /* Convert to initialized */ + if (flags & EXT4_GET_BLOCKS_CONVERT) + split_flag |=3D EXT4_EXT_DATA_VALID2; } flags |=3D EXT4_GET_BLOCKS_SPLIT_NOMERGE; return ext4_split_extent(handle, inode, path, map, split_flag, flags, @@ -3930,7 +3934,7 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, s= truct inode *inode, /* get_block() before submitting IO, split the extent */ if (flags & EXT4_GET_BLOCKS_SPLIT_NOMERGE) { path =3D ext4_split_convert_extents(handle, inode, map, path, - flags | EXT4_GET_BLOCKS_CONVERT, allocated); + flags, allocated); if (IS_ERR(path)) return path; /* --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 A65B226C3BD; Sat, 29 Nov 2025 10:35:32 +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=1764412535; cv=none; b=D2vVCoUuFAc+uV21sT5BWYpr09zqUftu609+54wHzQzsRCIJu5qiLwQwzw3yvxmMCi8/vxcdz3Fv053Rvq0C6X3CCBTbPPVGrmN8BbdXuaqu5jCk7C6er30IA6Y54DqAwLm9IIxIca18XG1KelabCXKBYgSQshpri/Jmg2G8E6o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412535; c=relaxed/simple; bh=jw15VeROEs1sm1eOVRtur4tbrLxmnin2G0JHvis4MeM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g33dPutNpNsSyRGgY56WhXEh2lPrMsgg3+7zKXwMzJnefo0sayb/A+dPojzzVQvMAdz/RULGreP1qDe73eSNHcrfRc/aaOCa2blLcqfUNproi94K0Ni50LMzQg0L1aPoTvAvHWX6jeZny3JbwuMGM3HZX6AqgUke+HklR3jeor0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dJRP55f6XzYQtnq; Sat, 29 Nov 2025 18:34:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 8FE171A14FE; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S8; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 04/14] ext4: correct the mapping status if the extent has been zeroed Date: Sat, 29 Nov 2025 18:32:36 +0800 Message-ID: <20251129103247.686136-5-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S8 X-Coremail-Antispam: 1UD129KBjvJXoW7Cr15XFW8XF1rGw15XF43ZFb_yoW8Cr18pa 4xAF1rGr409ayj9397uF48Zr1293WxGr47ZrWftrWY9as3Kr1Fgr15ta4FyFyrXay8uay7 ZFW0934UKa43C3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUriihUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Before submitting I/O and allocating blocks with the EXT4_GET_BLOCKS_PRE_IO flag set, ext4_split_convert_extents() may convert the target extent range to initialized due to ENOSPC, ENOMEM, or EQUOTA errors. However, it still marks the mapping as incorrectly unwritten. Although this may not seem to cause any practical problems, it will result in an unnecessary extent conversion operation after I/O completion. Therefore, it's better to correct the returned mapping status. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li --- fs/ext4/extents.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 91b56de60c90..daecf3f0b367 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3933,6 +3933,8 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, s= truct inode *inode, =20 /* get_block() before submitting IO, split the extent */ if (flags & EXT4_GET_BLOCKS_SPLIT_NOMERGE) { + int depth; + path =3D ext4_split_convert_extents(handle, inode, map, path, flags, allocated); if (IS_ERR(path)) @@ -3948,7 +3950,13 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, = struct inode *inode, err =3D -EFSCORRUPTED; goto errout; } - map->m_flags |=3D EXT4_MAP_UNWRITTEN; + /* Don't mark unwritten if the extent has been zeroed out. */ + path =3D ext4_find_extent(inode, map->m_lblk, path, flags); + if (IS_ERR(path)) + return path; + depth =3D ext_depth(inode); + if (ext4_ext_is_unwritten(path[depth].p_ext)) + map->m_flags |=3D EXT4_MAP_UNWRITTEN; goto out; } /* IO end_io complete, convert the filled extent to written */ --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 DE69F19C540; Sat, 29 Nov 2025 10:35:38 +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=1764412542; cv=none; b=J3HbnYCIcc6tYKmIRkiUesNg79NIlYedqOAoBJGvRpo1KIMWvumsoFcGoLbDQvfIxxcZqNOJLvUKvrXcJnHG924wjPLRFxzvTxEt25+DssOrl9G0QGTA3hcOjH3Mw21aACyrgUs/Vue2+CsHhxMspX9hQZwOUccN8YFQjM2ym/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412542; c=relaxed/simple; bh=HVBoB5IHmQ720ZdZa49JC6bOZSiel3XlOev/OUMySSE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=r8yYuBM3hwv0jV4euVkhLzTDxMUeW5mWQoblGAZZ6VOIivyaj0mPUc4234uH4TuSFqcvVrsL9sTAVaJkGU/Trt50yFTHBE3InoMb7MbNRfMm8k8EGIj8lIa3tuEVrnn6XwM6fOXWVpGduEvw/TNwIGwOj9ffgPG6GGK+HxKb/oM= 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.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPM3Lh4zKHMQS; Sat, 29 Nov 2025 18:34:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id A50DF1A1728; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S9; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 05/14] ext4: don't cache extent during splitting extent Date: Sat, 29 Nov 2025 18:32:37 +0800 Message-ID: <20251129103247.686136-6-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S9 X-Coremail-Antispam: 1UD129KBjvJXoWxAw17tF17tr1xKrW7Ww4fAFb_yoW5WF4kpF ZakF1UGr4kCw1vk34xAF4kK3409w4kGrW7Ar95Gw1Y9FyUJFyagF1xtw1YvFyrWr48Za45 Zr40kF1UCa4DAFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUma14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsG vfC2KfnxnUUI43ZEXa7VU1zpBDUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org --- fs/ext4/extents.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index daecf3f0b367..be9fd2ab8667 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3199,6 +3199,9 @@ static struct ext4_ext_path *ext4_split_extent_at(han= dle_t *handle, BUG_ON((split_flag & EXT4_EXT_DATA_VALID1) && (split_flag & EXT4_EXT_DATA_VALID2)); =20 + /* Do not cache extents that are in the process of being modified. */ + flags |=3D EXT4_EX_NOCACHE; + ext_debug(inode, "logical block %llu\n", (unsigned long long)split); =20 ext4_ext_show_leaf(inode, path); @@ -3381,6 +3384,9 @@ static struct ext4_ext_path *ext4_split_extent(handle= _t *handle, ee_len =3D ext4_ext_get_actual_len(ex); unwritten =3D ext4_ext_is_unwritten(ex); =20 + /* Do not cache extents that are in the process of being modified. */ + flags |=3D EXT4_EX_NOCACHE; + if (map->m_lblk + map->m_len < ee_block + ee_len) { split_flag1 =3D split_flag & EXT4_EXT_MAY_ZEROOUT; flags1 =3D flags | EXT4_GET_BLOCKS_SPLIT_NOMERGE; --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 A64AC267B92; Sat, 29 Nov 2025 10:35:32 +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=1764412535; cv=none; b=HgKD25geP+EiuS7IftoU/FVkEGn/wRND+cw/2/6KJmq5FGRcohvEkb21OdAbE1KpFW9UtVdjYkwu9xDRskWppB4XP6Dp7kb74PaTS6MjCqfbER0CeazQA7AeJuJPVZu+xi4+YRR5zgJyMqyZc7Q4aWMn4deBedTns06x00RDLjo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412535; c=relaxed/simple; bh=MbvmFFzVfSoKt0RgzX1oeI2mwk6A7k7UuP/6BZEfpeM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ELR4+eAe0lUzTvJt0sHNdktUy/2jqb0/+2Y7ZrrrXb/U5uogMBbGKuiNeQR6T7mLdUqGCFZXbISt/IgFcZpiJBf/ncj/Yt3DRv3OUjIa8IyCarocTOx9WCOS971PUk0qTS9oM+1P6DzW8gQYT454SMAbyj6jdqhw884qwmAvgWs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dJRP56k6TzYQtpT; Sat, 29 Nov 2025 18:34:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id B0A8C1A07BB; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S10; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 06/14] ext4: drop extent cache after doing PARTIAL_VALID1 zeroout Date: Sat, 29 Nov 2025 18:32:38 +0800 Message-ID: <20251129103247.686136-7-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S10 X-Coremail-Antispam: 1UD129KBjvJXoWxJw1rWFWrZw15AF4UurWkXrb_yoW5GrW5pa saka1UGr4kA348K34fG3WDtrn5uw18GrW7AryUGr1jga4DXryagrn7Ga1jvFySgFW8ZF15 Zr40ya45C3Z8AFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUma14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsG vfC2KfnxnUUI43ZEXa7VU1zpBDUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent. Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent. 0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten. 0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUWWWWWWWWUU] extent status tree [--DDDDDDDDZZ] Fix this issue by always cached extent status entry after zeroing out the second part. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index be9fd2ab8667..1094e4923451 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3319,8 +3319,16 @@ static struct ext4_ext_path *ext4_split_extent_at(ha= ndle_t *handle, * extent length and ext4_split_extent() split will the * first half again. */ - if (split_flag & EXT4_EXT_DATA_PARTIAL_VALID1) + if (split_flag & EXT4_EXT_DATA_PARTIAL_VALID1) { + /* + * Drop extent cache to prevent stale unwritten + * extents remaining after zeroing out. + */ + ext4_es_remove_extent(inode, + le32_to_cpu(zero_ex.ee_block), + ext4_ext_get_actual_len(&zero_ex)); goto fix_extent_len; + } =20 /* update the extent length and mark as initialized */ ex->ee_len =3D cpu_to_le16(ee_len); --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 DE853288C20; Sat, 29 Nov 2025 10:35:38 +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=1764412541; cv=none; b=VP0oExN51FJ2OCIFIBuAR+TevsP08YhOBnsrRGdjFms9CXY6DAXeZdxTNbYY/h1fVQw+nhfPV9KWnyw3lhkGbFz7QA3sQTEWFqaY6MKqRJc61dwLH27B8sFoDxPs7YA6R+9rVkkfREI5QNjsJac7fgdS9YJiAHwNqjbLwIBpxws= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412541; c=relaxed/simple; bh=SmSydm2kjWy8IltF7D7w7ZyiF50tx4tLTESyzkAB+jw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tI2t99L1CpvQaWH9PqWYbBQaW1ALYzMKZGAnVTEFswDAp+e6tc5auWVy/fJYWNIJS/d6ypWlI/w2I0yZxhRP90+1GgkbFhD96kvru9b+v1SVJwbsYm6uDHZGyVRH/+MiIyPjXay8r/O23tOXYckym5oCKwWLflVp/UREguC7i6I= 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.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPM4WQXzKHMQH; Sat, 29 Nov 2025 18:34:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id C98121A0C3B; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S11; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 07/14] ext4: drop extent cache when splitting extent fails Date: Sat, 29 Nov 2025 18:32:39 +0800 Message-ID: <20251129103247.686136-8-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S11 X-Coremail-Antispam: 1UD129KBjvJXoW7tF4xur4xCFW8Kw1ruF4kWFg_yoW8Wr4Dpr s7Ar1UWrn5u3W2krZrGayUZ3W7Ca1UGr47GFWfG3s8KF17XrWFgF17t3W0vFyFgFW8Wa43 Ar40yr1UAay3AFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUma14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsG vfC2KfnxnUUI43ZEXa7VU1zpBDUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 1094e4923451..945995d68c4d 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3267,7 +3267,7 @@ static struct ext4_ext_path *ext4_split_extent_at(han= dle_t *handle, =20 err =3D PTR_ERR(path); if (err !=3D -ENOSPC && err !=3D -EDQUOT && err !=3D -ENOMEM) - return path; + goto out_path; =20 /* * Get a new path to try to zeroout or fix the extent length. @@ -3281,7 +3281,7 @@ static struct ext4_ext_path *ext4_split_extent_at(han= dle_t *handle, if (IS_ERR(path)) { EXT4_ERROR_INODE(inode, "Failed split extent on %u, err %ld", split, PTR_ERR(path)); - return path; + goto out_path; } depth =3D ext_depth(inode); ex =3D path[depth].p_ext; @@ -3358,6 +3358,10 @@ static struct ext4_ext_path *ext4_split_extent_at(ha= ndle_t *handle, ext4_free_ext_path(path); path =3D ERR_PTR(err); } +out_path: + if (IS_ERR(path)) + /* Remove all remaining potentially stale extents. */ + ext4_es_remove_extent(inode, ee_block, ee_len); ext4_ext_show_leaf(inode, path); return path; } --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 DF37E288C2F; Sat, 29 Nov 2025 10:35:38 +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=1764412541; cv=none; b=s5ckvMLVlEi3/vB6WvKQJRYmsNA0uCidew68dpEv6AsUTKZ0mIYcTmNmwBVpR1BKRa4Xe46HAARcuezjNMufBw+z8huyYBifmClzX78FFCMTFBdUi06Dzu/oiZZhgUZpyE/Tjp7/k3ToWFavEmQsBBQKwFvo/63rZsh1vNcMlc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412541; c=relaxed/simple; bh=J9xDl5A5iwswn0zSvX3vOHrpKbNOm+R+P3Z+pJ+Gu60=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FB0MOFeibNsduPWvEBeSz1EUXpPVsScFy/hwfCj9hEyPBLwoqDlAOOVgoR7FJ2p2bHbRvpA8aEDq8FCQWX8qM7r59hrF/ZNqdxDjJ0IQK72YGxNSk3C66FRCJAMCF/+rGNvtLiCjU+yoXZqDn2CFfuEtGMewpmQ3tSoBZdYhFNM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPM5DYmzKHMQH; Sat, 29 Nov 2025 18:34:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id DDBC81A07BB; Sat, 29 Nov 2025 18:35:30 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S12; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 08/14] ext4: cleanup zeroout in ext4_split_extent_at() Date: Sat, 29 Nov 2025 18:32:40 +0800 Message-ID: <20251129103247.686136-9-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S12 X-Coremail-Antispam: 1UD129KBjvJXoWxGFWDCr47Jw18Jr1UZw1rCrg_yoWrWFy7pw nI9a4rGrn5J34UW3yxJF47Zr1jg3WfWw4UG3y3Gw1fGa17Xr9agFyfKay0qFyFgFWkXryY qr4rt34UC3ZrGFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUWMKtUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi zero_ex is a temporary variable used only for writing zeros and inserting extent status entry, it will not be directly inserted into the tree. Therefore, it can be assigned values from the target extent in various scenarios, eliminating the need to explicitly assign values to each variable individually. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Jan Kara Reviewed-by: Baokun Li --- fs/ext4/extents.c | 87 ++++++++++++++++++++--------------------------- 1 file changed, 36 insertions(+), 51 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 945995d68c4d..2cfce2c01208 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3287,63 +3287,48 @@ static struct ext4_ext_path *ext4_split_extent_at(h= andle_t *handle, ex =3D path[depth].p_ext; =20 if (EXT4_EXT_MAY_ZEROOUT & split_flag) { - if (split_flag & (EXT4_EXT_DATA_VALID1|EXT4_EXT_DATA_VALID2)) { - if (split_flag & EXT4_EXT_DATA_VALID1) { - err =3D ext4_ext_zeroout(inode, ex2); - zero_ex.ee_block =3D ex2->ee_block; - zero_ex.ee_len =3D cpu_to_le16( - ext4_ext_get_actual_len(ex2)); - ext4_ext_store_pblock(&zero_ex, - ext4_ext_pblock(ex2)); - } else { - err =3D ext4_ext_zeroout(inode, ex); - zero_ex.ee_block =3D ex->ee_block; - zero_ex.ee_len =3D cpu_to_le16( - ext4_ext_get_actual_len(ex)); - ext4_ext_store_pblock(&zero_ex, - ext4_ext_pblock(ex)); - } - } else { - err =3D ext4_ext_zeroout(inode, &orig_ex); - zero_ex.ee_block =3D orig_ex.ee_block; - zero_ex.ee_len =3D cpu_to_le16( - ext4_ext_get_actual_len(&orig_ex)); - ext4_ext_store_pblock(&zero_ex, - ext4_ext_pblock(&orig_ex)); - } + if (split_flag & EXT4_EXT_DATA_VALID1) + memcpy(&zero_ex, ex2, sizeof(zero_ex)); + else if (split_flag & EXT4_EXT_DATA_VALID2) + memcpy(&zero_ex, ex, sizeof(zero_ex)); + else + memcpy(&zero_ex, &orig_ex, sizeof(zero_ex)); + ext4_ext_mark_initialized(&zero_ex); =20 - if (!err) { + err =3D ext4_ext_zeroout(inode, &zero_ex); + if (err) + goto fix_extent_len; + + /* + * The first half contains partially valid data, the splitting + * of this extent has not been completed, fix extent length + * and ext4_split_extent() split will the first half again. + */ + if (split_flag & EXT4_EXT_DATA_PARTIAL_VALID1) { /* - * The first half contains partially valid data, the - * splitting of this extent has not been completed, fix - * extent length and ext4_split_extent() split will the - * first half again. + * Drop extent cache to prevent stale unwritten + * extents remaining after zeroing out. */ - if (split_flag & EXT4_EXT_DATA_PARTIAL_VALID1) { - /* - * Drop extent cache to prevent stale unwritten - * extents remaining after zeroing out. - */ - ext4_es_remove_extent(inode, + ext4_es_remove_extent(inode, le32_to_cpu(zero_ex.ee_block), ext4_ext_get_actual_len(&zero_ex)); - goto fix_extent_len; - } - - /* update the extent length and mark as initialized */ - ex->ee_len =3D cpu_to_le16(ee_len); - ext4_ext_try_to_merge(handle, inode, path, ex); - err =3D ext4_ext_dirty(handle, inode, path + path->p_depth); - if (!err) - /* update extent status tree */ - ext4_zeroout_es(inode, &zero_ex); - /* If we failed at this point, we don't know in which - * state the extent tree exactly is so don't try to fix - * length of the original extent as it may do even more - * damage. - */ - goto out; + goto fix_extent_len; } + + /* update the extent length and mark as initialized */ + ex->ee_len =3D cpu_to_le16(ee_len); + ext4_ext_try_to_merge(handle, inode, path, ex); + err =3D ext4_ext_dirty(handle, inode, path + path->p_depth); + if (!err) + /* update extent status tree */ + ext4_zeroout_es(inode, &zero_ex); + /* + * If we failed at this point, we don't know in which + * state the extent tree exactly is so don't try to fix + * length of the original extent as it may do even more + * damage. + */ + goto out; } =20 fix_extent_len: --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 9A40F2C0263; Sat, 29 Nov 2025 10:35:43 +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=1764412546; cv=none; b=tkIsm+ZyzR6pPlmI6QQ2kGSJnf8s6HAK30hLK/aZMWlnsvsG/dCs5mmXBlDtGRNDWyLWLQEF5hNjadnVmF+Y4TAOj3ix1fNzc8cLeXSwahgBNZM7vgMk+p6X+xbHctRQgDAbqafIq75yaX9MrTNGJ/8dntdwvsbdcYL/7YAM/DQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412546; c=relaxed/simple; bh=KzoY1o5o5HkeAz5GtXXnuXi2hP9iQuJUxW+HhuJTzWE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ahGOmvpcyqiqcTP5ifsJUEjHPEQra1sI7e8nFF7pqXdyRJMROiaoz2B5Q2Ccm4szGVhF7u6ckzQ9Yi/NPViN5HGYKrM8y9PoP2vj/S9rXPsrJ4JWwUfUS1KUXe9LvPCv1HxweBroN8zngynxKhOYmPbfUAOmkvAx1ANHbdRg6xA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPM5vVYzKHMQH; Sat, 29 Nov 2025 18:34:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 014DA1A07BD; Sat, 29 Nov 2025 18:35:31 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S13; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 09/14] ext4: cleanup useless out label in __es_remove_extent() Date: Sat, 29 Nov 2025 18:32:41 +0800 Message-ID: <20251129103247.686136-10-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S13 X-Coremail-Antispam: 1UD129KBjvJXoW7uFW3ZrW8Ar4DWrykWr4Uurg_yoW8ZrW5pa 1Fv34DWry8Zw40g397tw1Durya93WxGFW7Wryftw1S9FyYqryFgr10ya1YvFyFqFW8K3yU XF40yw1jkay7tFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUWMKtUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The out label in __es_remove_extent() is just return err value, we can return it directly if something bad happens. Therefore, remove the useless out label and rename out_get_reserved to out. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li --- fs/ext4/extents_status.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index e04fbf10fe4f..04d56f8f6c0c 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -1434,7 +1434,7 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, struct extent_status orig_es; ext4_lblk_t len1, len2; ext4_fsblk_t block; - int err =3D 0; + int err; bool count_reserved =3D true; struct rsvd_count rc; =20 @@ -1443,9 +1443,9 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, =20 es =3D __es_tree_search(&tree->root, lblk); if (!es) - goto out; + return 0; if (es->es_lblk > end) - goto out; + return 0; =20 /* Simply invalidate cache_es. */ tree->cache_es =3D NULL; @@ -1480,7 +1480,7 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, =20 es->es_lblk =3D orig_es.es_lblk; es->es_len =3D orig_es.es_len; - goto out; + return err; } } else { es->es_lblk =3D end + 1; @@ -1494,7 +1494,7 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, if (count_reserved) count_rsvd(inode, orig_es.es_lblk + len1, orig_es.es_len - len1 - len2, &orig_es, &rc); - goto out_get_reserved; + goto out; } =20 if (len1 > 0) { @@ -1536,11 +1536,10 @@ static int __es_remove_extent(struct inode *inode, = ext4_lblk_t lblk, } } =20 -out_get_reserved: +out: if (count_reserved) *reserved =3D get_rsvd(inode, end, es, &rc); -out: - return err; + return 0; } =20 /* --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 9AF9A2C0268; Sat, 29 Nov 2025 10:35:43 +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=1764412546; cv=none; b=spnnTzrblRSmtDE0sEvuNc7mcZBsSwZvri2gpyqoyiddLC4OyPPs2/eAW0ofD8NURI8zxvjK+/TFbV/FLld8HNxakX7iE6lc42hyFnMyuGy3KwmfUe35RWoNloRnv4iPqX/1PR7pcox14CxMaj08T1L21qxilIkPfjorBQUZPBE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412546; c=relaxed/simple; bh=w2SaBpsWy6o6mWPdQStJIN2ayFwYAVI1TulknmC9MnU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZXqNyNrwkTxKxrOKit02N+09aWhlaLoDd6ALvykCiphN5bzw8k73Na/rJYrzyOfEndSxD44lhEOb5c1kyXKNiq7lVbaQn0+SeZ0AKxxgS8zYLCOSbboK57BJnAUR26xBFH3wPMGWs1lJmjE+Ymmk3eJkxYGSY9YwPfsqFLWCE7Q= 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.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPM6Sm8zKHMRN; Sat, 29 Nov 2025 18:34:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 189EA1A1727; Sat, 29 Nov 2025 18:35:31 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S14; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 10/14] ext4: make __es_remove_extent() check extent status Date: Sat, 29 Nov 2025 18:32:42 +0800 Message-ID: <20251129103247.686136-11-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S14 X-Coremail-Antispam: 1UD129KBjvJXoW3Jr1DCF1DGw47WFyfJw4Dtwb_yoW7urW8pF ZrZr1UGryUXayI93yxtw1UWr1ag3W0krW7JrZxKw1fuF15Jrya9F10yFy2vF9YqrW0g3WU ZF40yw1UGa12ga7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUWMKtUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Currently, __es_remove_extent() unconditionally removes extent status entries within the specified range. In order to prepare for extending the ext4_es_cache_extent() function to cache on-disk extents, which may overwrite some existing short-length extents with the same status, allow __es_remove_extent() to check the specified extent type before removing it, and return error and pass out the conflicting extent if the status does not match. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li --- fs/ext4/extents_status.c | 49 +++++++++++++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 8 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 04d56f8f6c0c..818007bb613f 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -178,7 +178,8 @@ static struct kmem_cache *ext4_pending_cachep; static int __es_insert_extent(struct inode *inode, struct extent_status *n= ewes, struct extent_status *prealloc); static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, - ext4_lblk_t end, int *reserved, + ext4_lblk_t end, unsigned int status, + int *reserved, struct extent_status *res, struct extent_status *prealloc); static int es_reclaim_extents(struct ext4_inode_info *ei, int *nr_to_scan); static int __es_shrink(struct ext4_sb_info *sbi, int nr_to_scan, @@ -242,6 +243,21 @@ static inline void ext4_es_inc_seq(struct inode *inode) WRITE_ONCE(ei->i_es_seq, ei->i_es_seq + 1); } =20 +static inline int __es_check_extent_status(struct extent_status *es, + unsigned int status, + struct extent_status *res) +{ + if (ext4_es_type(es) & status) + return 0; + + if (res) { + res->es_lblk =3D es->es_lblk; + res->es_len =3D es->es_len; + res->es_pblk =3D es->es_pblk; + } + return -EINVAL; +} + /* * search through the tree for an delayed extent with a given offset. If * it can't be found, try to find next extent. @@ -929,7 +945,7 @@ void ext4_es_insert_extent(struct inode *inode, ext4_lb= lk_t lblk, pr =3D __alloc_pending(true); write_lock(&EXT4_I(inode)->i_es_lock); =20 - err1 =3D __es_remove_extent(inode, lblk, end, &resv_used, es1); + err1 =3D __es_remove_extent(inode, lblk, end, 0, &resv_used, NULL, es1); if (err1 !=3D 0) goto error; /* Free preallocated extent if it didn't get used. */ @@ -1409,23 +1425,27 @@ static unsigned int get_rsvd(struct inode *inode, e= xt4_lblk_t end, return rc->ndelayed; } =20 - /* * __es_remove_extent - removes block range from extent status tree * * @inode - file containing range * @lblk - first block in range * @end - last block in range + * @status - the extent status to be checked * @reserved - number of cluster reservations released + * @res - return the extent if the status is not match * @prealloc - pre-allocated es to avoid memory allocation failures * * If @reserved is not NULL and delayed allocation is enabled, counts * block/cluster reservations freed by removing range and if bigalloc - * enabled cancels pending reservations as needed. Returns 0 on success, - * error code on failure. + * enabled cancels pending reservations as needed. If @status is not + * zero, check extent status type while removing extent, return -EINVAL + * and pass out the extent through @res if not match. Returns 0 on + * success, error code on failure. */ static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, - ext4_lblk_t end, int *reserved, + ext4_lblk_t end, unsigned int status, + int *reserved, struct extent_status *res, struct extent_status *prealloc) { struct ext4_es_tree *tree =3D &EXT4_I(inode)->i_es_tree; @@ -1440,6 +1460,8 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, =20 if (reserved =3D=3D NULL || !test_opt(inode->i_sb, DELALLOC)) count_reserved =3D false; + if (status =3D=3D 0) + status =3D ES_TYPE_MASK; =20 es =3D __es_tree_search(&tree->root, lblk); if (!es) @@ -1447,6 +1469,10 @@ static int __es_remove_extent(struct inode *inode, e= xt4_lblk_t lblk, if (es->es_lblk > end) return 0; =20 + err =3D __es_check_extent_status(es, status, res); + if (err) + return err; + /* Simply invalidate cache_es. */ tree->cache_es =3D NULL; if (count_reserved) @@ -1509,6 +1535,9 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, } =20 while (es && ext4_es_end(es) <=3D end) { + err =3D __es_check_extent_status(es, status, res); + if (err) + return err; if (count_reserved) count_rsvd(inode, es->es_lblk, es->es_len, es, &rc); node =3D rb_next(&es->rb_node); @@ -1524,6 +1553,10 @@ static int __es_remove_extent(struct inode *inode, e= xt4_lblk_t lblk, if (es && es->es_lblk < end + 1) { ext4_lblk_t orig_len =3D es->es_len; =20 + err =3D __es_check_extent_status(es, status, res); + if (err) + return err; + len1 =3D ext4_es_end(es) - end; if (count_reserved) count_rsvd(inode, es->es_lblk, orig_len - len1, @@ -1581,7 +1614,7 @@ void ext4_es_remove_extent(struct inode *inode, ext4_= lblk_t lblk, * is reclaimed. */ write_lock(&EXT4_I(inode)->i_es_lock); - err =3D __es_remove_extent(inode, lblk, end, &reserved, es); + err =3D __es_remove_extent(inode, lblk, end, 0, &reserved, NULL, es); if (err) goto error; /* Free preallocated extent if it didn't get used. */ @@ -2173,7 +2206,7 @@ void ext4_es_insert_delayed_extent(struct inode *inod= e, ext4_lblk_t lblk, } write_lock(&EXT4_I(inode)->i_es_lock); =20 - err1 =3D __es_remove_extent(inode, lblk, end, NULL, es1); + err1 =3D __es_remove_extent(inode, lblk, end, 0, NULL, NULL, es1); if (err1 !=3D 0) goto error; /* Free preallocated extent if it didn't get used. */ --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 5775019C540; Sat, 29 Nov 2025 10:35:32 +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=1764412535; cv=none; b=eQiFT4k6qZ1CZOGb6nVM7fNlQfLbKmhWTdOepPJFyBFZP/topCIl1PAoNH+B2UVdwyXiiVyp83gHB6Z347K45CoqeBWSNg/7V4eyG1vHx/BvUxBNMgIR6uLCysE96ZvHVan8F+sfuDD5GGi9MugeEEy/CYSTUCxPr8U3QMYXegA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412535; c=relaxed/simple; bh=19oN0uEZyg2y4qgD3lZNb8ms2AUhmHEcoCmgnYUmYFc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KP7JxcGIByHVT6uxuqov1e8SOFbYZoqVTxbhd4+PryCHOtM/vm7+TaguEyViVT8OLvWZi06phlTEm9bOfa3B9PSiNARBYYLZwxgBcSowd3kq2pd86KOZp1BLs8I9SeeUoujmbliuCCXDIUoRbSU9nQoFEkXBTd5NqcqFr7xKCKA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dJRP62jyYzYQtpm; Sat, 29 Nov 2025 18:34:34 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 27F681A07C0; Sat, 29 Nov 2025 18:35:31 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S15; Sat, 29 Nov 2025 18:35:30 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 11/14] ext4: make ext4_es_cache_extent() support overwrite existing extents Date: Sat, 29 Nov 2025 18:32:43 +0800 Message-ID: <20251129103247.686136-12-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S15 X-Coremail-Antispam: 1UD129KBjvJXoWxury7GFW3Ar15Kw18JF4Utwb_yoWrCr1xp3 9xCr15Jr1kXa4kKa4fJa1UXry5Kw4rJrW7Jr93Kr1fCFy5JFyagF1jka4jvryfWrW8Xr1Y vF40kw1UGa1UC3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUWMKtUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Currently, ext4_es_cache_extent() is used to load extents into the extent status tree when reading on-disk extent blocks. But it inserts information into the extent status tree if and only if there isn't information about the specified range already. So it only used for the initial loading and does not support overwrit extents. However, there are many other places in ext4 where on-disk extents are inserted into the extent status tree, such as in ext4_map_query_blocks(). Currently, they call ext4_es_insert_extent() to perform the insertion, but they don't modify the extents, so ext4_es_cache_extent() would be a more appropriate choice. However, when ext4_map_query_blocks() inserts an extent, it may overwrite a short existing extent of the same type. Therefore, to prepare for the replacements, we need to extend ext4_es_cache_extent() to allow it to overwrite existing extents with the same status. So it checks the found extents before removing and inserting. (There is one exception, a hole in the on-disk extent but a delayed extent in the extent status tree is allowed.) In addition, since cached extents can be more lenient than the extents they modify and do not involve modifying reserved blocks, it is not necessary to ensure that the insertion operation succeeds as strictly as in the ext4_es_insert_extent() function. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li --- fs/ext4/extents_status.c | 50 ++++++++++++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 7 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 818007bb613f..48f04aef2f2e 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -1014,17 +1014,24 @@ void ext4_es_insert_extent(struct inode *inode, ext= 4_lblk_t lblk, } =20 /* - * ext4_es_cache_extent() inserts information into the extent status - * tree if and only if there isn't information about the range in - * question already. + * ext4_es_cache_extent() inserts information into the extent status tree + * only if there is no existing information about the specified range or + * if the existing extents have the same status. + * + * Note that this interface is only used for caching on-disk extent + * information and cannot be used to convert existing extents in the extent + * status tree. To convert existing extents, use ext4_es_insert_extent() + * instead. */ void ext4_es_cache_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t len, ext4_fsblk_t pblk, unsigned int status) { struct extent_status *es; - struct extent_status newes; + struct extent_status chkes, newes; ext4_lblk_t end =3D lblk + len - 1; + bool conflict =3D false; + int err; =20 if (EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY) return; @@ -1040,11 +1047,40 @@ void ext4_es_cache_extent(struct inode *inode, ext4= _lblk_t lblk, BUG_ON(end < lblk); =20 write_lock(&EXT4_I(inode)->i_es_lock); - es =3D __es_tree_search(&EXT4_I(inode)->i_es_tree.root, lblk); - if (!es || es->es_lblk > end) - __es_insert_extent(inode, &newes, NULL); + if (es && es->es_lblk <=3D end) { + /* Found an extent that covers the entire range. */ + if (es->es_lblk <=3D lblk && es->es_lblk + es->es_len > end) { + if (__es_check_extent_status(es, status, &chkes)) + conflict =3D true; + goto unlock; + } + /* Check and remove all extents in range. */ + err =3D __es_remove_extent(inode, lblk, end, status, NULL, + &chkes, NULL); + if (err) { + if (err =3D=3D -EINVAL) + conflict =3D true; + goto unlock; + } + } + __es_insert_extent(inode, &newes, NULL); +unlock: write_unlock(&EXT4_I(inode)->i_es_lock); + if (!conflict) + return; + /* + * A hole in the on-disk extent but a delayed extent in the extent + * status tree, is allowed. + */ + if (status =3D=3D EXTENT_STATUS_HOLE && + ext4_es_type(&chkes) =3D=3D EXTENT_STATUS_DELAYED) + return; + + ext4_warning_inode(inode, + "ES cache extent failed: add [%d,%d,%llu,0x%x] conflict with existin= g [%d,%d,%llu,0x%x]\n", + lblk, len, pblk, status, chkes.es_lblk, chkes.es_len, + ext4_es_pblock(&chkes), ext4_es_status(&chkes)); } =20 /* --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 34DAB2BE05F; Sat, 29 Nov 2025 10:35:44 +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=1764412547; cv=none; b=QsyGaCs2vTytLr11DaAzNZGxeNLLEvOoL/m+V1Y5E7E/jKYuWXrM0OrEA5S0t6PwwqNJs+zsgfHy6IStFdk5NXp+e3kr0RjNad6qbcFn0yuO74LcgYs6ZVdemGdoK1XWG6kdKEmhIG7IDsQyDO8SXsMs5N7OkgPHEiml1aOL1OM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412547; c=relaxed/simple; bh=5lBdebcKv0F9gE4PU+P25Zgj1sz+8kf8Ad43c1GbPVM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mkEb9G447BtZ97GYORB44juCOYlGizydzgW7w/oRAXUAb1xHt9s4IBC0NXUiihi1Mx6l/E7FECHkfwdjQqUMMfcA22A6lDx9ZmXly5L1GIgduvbcRVaCvKCvryY43B0OreLj9AOQMPBupSs4Z1P5Rjfq21SW43kHtzDYmzSKRbQ= 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.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPN050yzKHMRY; Sat, 29 Nov 2025 18:34:48 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 324B61A1727; Sat, 29 Nov 2025 18:35:31 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S16; Sat, 29 Nov 2025 18:35:31 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 12/14] ext4: adjust the debug info in ext4_es_cache_extent() Date: Sat, 29 Nov 2025 18:32:44 +0800 Message-ID: <20251129103247.686136-13-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S16 X-Coremail-Antispam: 1UD129KBjvJXoWruw4fCr43Ary5Cw4rCFy8Zrb_yoW8JF45pa s3CF1UJrWrZ3yq9a4xWa18Cry3Gay8GrW7WrZ7tw1fuay8ZFyrKFnFyFyYvFyUXFWxX39x ZF40kw1UWa12y3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUWMKtUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Print a trace point after successfully inserting an extent in the ext4_es_cache_extent() function. Additionally, similar to other extent cache operation functions, call ext4_print_pending_tree() to display the extent debug information of the inode when in ES_DEBUG mode. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li --- fs/ext4/extents_status.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 48f04aef2f2e..0529c603ee88 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -1039,7 +1039,6 @@ void ext4_es_cache_extent(struct inode *inode, ext4_l= blk_t lblk, newes.es_lblk =3D lblk; newes.es_len =3D len; ext4_es_store_pblock_status(&newes, pblk, status); - trace_ext4_es_cache_extent(inode, &newes); =20 if (!len) return; @@ -1065,6 +1064,8 @@ void ext4_es_cache_extent(struct inode *inode, ext4_l= blk_t lblk, } } __es_insert_extent(inode, &newes, NULL); + trace_ext4_es_cache_extent(inode, &newes); + ext4_es_print_tree(inode); unlock: write_unlock(&EXT4_I(inode)->i_es_lock); if (!conflict) --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 9CDD42C026C; Sat, 29 Nov 2025 10:35:43 +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=1764412546; cv=none; b=ilm9ayCaG4GLMclVEGguD2sgbibB9CAlb9zJGsXr01M7JjC6wVZsQ7sZH8EKl8m/tOoIP24uxFawj0OWCIQEO/Xk2shVQ0A10/grTJQXQHXBGzPAZG//VjyPFWRWMD1L7BuhOaIxxlBvYj+m1hLXIHFOU6c+Xb4kbiM/V/Wr7Jc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412546; c=relaxed/simple; bh=5LWhOe7zaJdqz/lKjonq2GVR4Bk7kMv2d0wdGV4dEWk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rv8gguvAxicV1tl4QWnin9vGYiI1pCIBGjulqBbO8ArclRsWjNO0aBmwfRik0/qaeU9YqUdURNgUF8PzqKgc1sSCy+DtjWfCLeKQowjV6hr5Xd9RWCFQIwsvkNKNGjvkCmYe/ZcZAEGtgrulg28O+/EDCFjlNm24vCLkFq0eXiM= 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.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJRPN0j0WzKHMRY; Sat, 29 Nov 2025 18:34:48 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 423021A10DF; Sat, 29 Nov 2025 18:35:31 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S17; Sat, 29 Nov 2025 18:35:31 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 13/14] ext4: replace ext4_es_insert_extent() when caching on-disk extents Date: Sat, 29 Nov 2025 18:32:45 +0800 Message-ID: <20251129103247.686136-14-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S17 X-Coremail-Antispam: 1UD129KBjvJXoWxWF4DJr4rGF4kAr4fur4UJwb_yoW5Aw4rpr ZrCrn5Gws8Ww1q9FWxJF4UZF15C3WakrW7Gw4IvryrZayrJFyfJF1jyF4IvFWvqrW0qw1r XF4UK34UCayfGa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUWMKtUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi In ext4, the remaining places for inserting extents into the extent status tree within ext4_ext_determine_insert_hole() and ext4_map_query_blocks() directly cache on-disk extents. We can use ext4_es_cache_extent() instead of ext4_es_insert_extent() in these cases. This will help reduce unnecessary increases in extent sequence numbers and cache invalidations after supporting IOMAP in the future. Suggested-by: Jan Kara Signed-off-by: Zhang Yi Reviewed-by: Baokun Li --- fs/ext4/extents.c | 3 +-- fs/ext4/inode.c | 18 +++++++++--------- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 2cfce2c01208..27eb2c1df012 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4192,8 +4192,7 @@ static ext4_lblk_t ext4_ext_determine_insert_hole(str= uct inode *inode, insert_hole: /* Put just found gap into cache to speed up subsequent requests */ ext_debug(inode, " -> %u:%u\n", hole_start, len); - ext4_es_insert_extent(inode, hole_start, len, ~0, - EXTENT_STATUS_HOLE, false); + ext4_es_cache_extent(inode, hole_start, len, ~0, EXTENT_STATUS_HOLE); =20 /* Update hole_len to reflect hole size after lblk */ if (hole_start !=3D lblk) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index eeb3ec4c2a9a..bb8165582840 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -504,8 +504,8 @@ static int ext4_map_query_blocks_next_in_leaf(handle_t = *handle, retval =3D ext4_ext_map_blocks(handle, inode, &map2, 0); =20 if (retval <=3D 0) { - ext4_es_insert_extent(inode, map->m_lblk, map->m_len, - map->m_pblk, status, false); + ext4_es_cache_extent(inode, map->m_lblk, map->m_len, + map->m_pblk, status); return map->m_len; } =20 @@ -526,13 +526,13 @@ static int ext4_map_query_blocks_next_in_leaf(handle_= t *handle, */ if (map->m_pblk + map->m_len =3D=3D map2.m_pblk && status =3D=3D status2) { - ext4_es_insert_extent(inode, map->m_lblk, - map->m_len + map2.m_len, map->m_pblk, - status, false); + ext4_es_cache_extent(inode, map->m_lblk, + map->m_len + map2.m_len, map->m_pblk, + status); map->m_len +=3D map2.m_len; } else { - ext4_es_insert_extent(inode, map->m_lblk, map->m_len, - map->m_pblk, status, false); + ext4_es_cache_extent(inode, map->m_lblk, map->m_len, + map->m_pblk, status); } =20 return map->m_len; @@ -574,8 +574,8 @@ static int ext4_map_query_blocks(handle_t *handle, stru= ct inode *inode, map->m_len =3D=3D orig_mlen) { status =3D map->m_flags & EXT4_MAP_UNWRITTEN ? EXTENT_STATUS_UNWRITTEN : EXTENT_STATUS_WRITTEN; - ext4_es_insert_extent(inode, map->m_lblk, map->m_len, - map->m_pblk, status, false); + ext4_es_cache_extent(inode, map->m_lblk, map->m_len, + map->m_pblk, status); } else { retval =3D ext4_map_query_blocks_next_in_leaf(handle, inode, map, orig_mlen); --=20 2.46.1 From nobody Mon Dec 1 22:36:27 2025 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 27A10285CBC; Sat, 29 Nov 2025 10:35: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=1764412539; cv=none; b=Aie9IW9cBFM+MGfsIoxeNlJ5bGavDLoOAHmldCx6t3H5GKxYFdjb6A78HzCvxs+dyhZejhqmI1TKQ+P1nfy+oZH+WV/VnaE/Vr1opczwtGSufW/oX9YCoipGsQKTNjpb+S9wAcAhaI2LFSEfu0Xp+bfmWOCk2x0psWxb6lal/OY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764412539; c=relaxed/simple; bh=9kWre2nZJcsb8KlJ5MGjDaPeHGKcZypCKa5U4lhaVMM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UzYIkCe9u/kzI0CHTT/2rG7xVobS4HUbEM24fYxzkOQ2K3WP/ikSydhBdpzrz3xTyKpYqF8gdB3W8IGXgtiQk4JNH+CQqdHJ4siw5gWZbAEFqt9nEJfUfm7jmQwq5GefEbiVH1omeIpctncXKkmc/vZoUYevcwKaPiOA6/QHiVU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dJRP645wSzYQtpm; Sat, 29 Nov 2025 18:34:34 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 557981A07C0; Sat, 29 Nov 2025 18:35:31 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgAnhXtfzCpp_56qCQ--.62661S18; Sat, 29 Nov 2025 18:35:31 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v3 14/14] ext4: drop the TODO comment in ext4_es_insert_extent() Date: Sat, 29 Nov 2025 18:32:46 +0800 Message-ID: <20251129103247.686136-15-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251129103247.686136-1-yi.zhang@huaweicloud.com> References: <20251129103247.686136-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: Syh0CgAnhXtfzCpp_56qCQ--.62661S18 X-Coremail-Antispam: 1UD129KBjvJXoW7uF4kXw45Gr4kKF4kXw1rXrb_yoW8Jw4kpr nxCw18Jr4fXa1vkayxGF4UXryfKaykGrW7GrZ7Kw1fKFW5JryS9F1qyFWYvFyfWrWxJrW5 ZF40kw1UWa1UJaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUWMKtUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Now we have ext4_es_cache_extent() to cache on-disk extents instead of ext4_es_insert_extent(), so drop the TODO comment. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li --- fs/ext4/extents_status.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 0529c603ee88..fc83e7e2ca9e 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -898,7 +898,8 @@ static int __es_insert_extent(struct inode *inode, stru= ct extent_status *newes, =20 /* * ext4_es_insert_extent() adds information to an inode's extent - * status tree. + * status tree. This interface is used for modifying extents. To cache + * on-disk extents, use ext4_es_cache_extent() instead. */ void ext4_es_insert_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t len, ext4_fsblk_t pblk, @@ -977,10 +978,6 @@ void ext4_es_insert_extent(struct inode *inode, ext4_l= blk_t lblk, } pending =3D err3; } - /* - * TODO: For cache on-disk extents, there is no need to increment - * the sequence counter, this requires future optimization. - */ ext4_es_inc_seq(inode); error: write_unlock(&EXT4_I(inode)->i_es_lock); --=20 2.46.1