From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC4053F5BC5; Tue, 14 Jul 2026 08:09:11 +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=1784016554; cv=none; b=DyA44mNzSUgRxr0jDesTtJ38Q/WPK1xCVd424hca+7FqO7vyVOjQ+ycyxSjtCp8BGuB8py0Cd/DF9SVbvkc6YSPY9cc8d1sWHfnJocE6TXmq6lEB9KQiljgcCseP3qW7J/F0wEsz1Kw6xjrH2ttOf07QPXaaK/BcTrcxQ/BuGh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016554; c=relaxed/simple; bh=rTqNLMkj5qVxE9AC6BeTJP5Ra6PABzocZjpFwn8p8kA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BhuCEzXDxZpgOXTrQkcWHYZ+YlzoGaN9QEGXZ9GZUMvUzYs90SMaxned8NGxW+YcRL8DcFPpLrB6slO6qIvXeOtmCaZyJZsXT0mTu9Jym43pXwCLF3Y7mEOc+FH2191RvF99G1mm7eEcULaNPZGqumOQQ67LyJG9mt55yzFE/5c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gzsPs5jdhzKHMNd; Tue, 14 Jul 2026 16:08:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 2860540766; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S5; Tue, 14 Jul 2026 16:09:03 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 1/9] ext4: use FGP_WRITEBEGIN for tail block zeroing Date: Tue, 14 Jul 2026 16:00:36 +0800 Message-ID: <20260714080044.4038124-2-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S5 X-Coremail-Antispam: 1UD129KBjvdXoWrur4DWw4fAryUKrW3ZF4xWFg_yoWDurb_Ja 4vqw48Ww45Xwn3uFsYya9Iqr1vvFyrKr4fCF48JFn3WryFvan5GrnYyFyrtFW7Wr4jgrZ8 ur1xXrWftF17WjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbkxFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUGwA2048vs2IY02 0Ec7CjxVAFwI0_Gr0_Xr1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2AI xVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20x vE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xv r2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2IY04 v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j 6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7 AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE 2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcV C2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2Kfnx nUUI43ZEXa7VUjrHUDUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi ext4_load_tail_bh() returns a locked folio that callers immediately mutate through folio_zero_range() and mark_buffer_dirty(). Use FGP_WRITEBEGIN so that, on backing devices that require stable writes, __filemap_get_folio() waits for writeback to finish before returning the folio; on regular devices the wait is a no-op. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index c2c2d6ac7f3d..7b2face041ef 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4037,7 +4037,7 @@ static struct buffer_head *ext4_load_tail_bh(struct i= node *inode, loff_t from) int err =3D 0; =20 folio =3D __filemap_get_folio(mapping, from >> PAGE_SHIFT, - FGP_LOCK | FGP_ACCESSED | FGP_CREAT, + FGP_WRITEBEGIN | FGP_ACCESSED, mapping_gfp_constraint(mapping, ~__GFP_FS)); if (IS_ERR(folio)) return ERR_CAST(folio); --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 014A43F5BD8; Tue, 14 Jul 2026 08:09:11 +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=1784016555; cv=none; b=Ol/Pl9UQsNjNgC/zBXlbNRck4toXsZSZ8JjDejFvd6tuhxoBvRgbytI+dm+koFXiFXGhvz6H17l6ddZ1TrJBRTqPJVi0WXWQHlLH+rbwjkK28lOmorHIqnoxb0/tCzsKHrGRop2OthQ6N8mY4dh+vq3du/vcsN0Vpawmi8N2Kcg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016555; c=relaxed/simple; bh=+2tXDBKPO/QuwbK836VP4RK5OIf2/gxeCPuU7Uo8OQ4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gNmUG6H63tUxE5vcAmVsGb3CjX9odbJsuREhefr5UoOch2m/vVrMr3s1kvkoltTeFHrPLCWQTsCAMcTOq36UQXUc74KvuyKgw4t7yu9h4Qs9yPqXJlL6AOHnKDyCe6/Sm786xH68ZrLNqwvYShhClhusA7zGR8L6bJLiD13dmnc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.198]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gzsQ91ksKzYQtll; Tue, 14 Jul 2026 16:08:49 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 37FA440605; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S6; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 2/9] ext4: skip tail block zeroing for inline data files Date: Tue, 14 Jul 2026 16:00:37 +0800 Message-ID: <20260714080044.4038124-3-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S6 X-Coremail-Antispam: 1UD129KBjvJXoW7CFyUWw1rCryruFyktw17GFg_yoW8XF1rpa 45G34DGrWku3sFga9aqr1xWw1ag3WfWr45JFWagr18Zay3Gr1xKFnI93W5XF1jyrW3A3y0 qFW5XFy7Cw17ArJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI 8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwAC jcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka0x kIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1V AY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAI cVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjfUOdgAUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi ext4_block_zero_eof() is called from ext4_write_checks() on every append write beyond EOF. For inline data files, ext4_get_block() returns -ERANGE when ext4_load_tail_bh() looks up the tail block. However, this error is currently ignored because the return value of ext4_get_block() in ext4_load_tail_bh() is discarded. Before we fix ext4_load_tail_bh() to properly propagate the error, skip the zeroing for inline data inodes to avoid unnecessary failures or confusion. Fixes: 3f60efd65412d ("ext4: zero post-EOF partial block before appending w= rite") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/inode.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 7b2face041ef..3ce925ca0769 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4218,6 +4218,14 @@ int ext4_block_zero_eof(struct inode *inode, loff_t = from, loff_t end) offset =3D from & (blocksize - 1); if (!offset || from >=3D end) return 0; + /* + * Inline data has no tail block to zero out. Note that a race with + * ext4_page_mkwrite() converting inline data to an extent without + * holding i_rwsem is safe, as that path zeroes the full block before + * copying in the inline data. + */ + if (ext4_has_inline_data(inode)) + return 0; /* If we are processing an encrypted inode during orphan list handling */ if (IS_ENCRYPTED(inode) && !fscrypt_has_encryption_key(inode)) return 0; --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC35C3F482B; Tue, 14 Jul 2026 08:09:11 +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=1784016556; cv=none; b=tfZ5DzpTl2KK/S9wjgEjVkr1PGATemM/j1pMMIwdPgMjC4zxnWjaUIAcfP9VsEfV8OHlLo2Q4xsWp4cwrdI94wwxnY4hbajLWy+m0TQBQObsqG21pYT5HqbUeM9PYvFgYzB6xemBxwVmVoC0WPfGhDbz58P6/oC8+NI1fK8/4hs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016556; c=relaxed/simple; bh=6/HSFyRBJWLh+B4KbOQib665p5+oSGwCYKmZUqcwbP0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c/tuzVd6ig1HHxpAfgtiB2Jng1OLz6jUlVTE3DFOwJJ7/KOn6+/av7LmzoLb1YcFuecnLDgLx+Yvc6/ICJAwB6Vg2pafeNVwnp6hJ3LBwt5huKQDeeQdGwS4+Pza2faLrlppXG/vfRd6TzBhMEkHePfiId3P3QqHZN6GNlGfcf8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gzsPs6BPYzKHMNl; Tue, 14 Jul 2026 16:08:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 446134076E; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S7; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 3/9] ext4: check return value of ext4_get_block() in ext4_load_tail_bh() Date: Tue, 14 Jul 2026 16:00:38 +0800 Message-ID: <20260714080044.4038124-4-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S7 X-Coremail-Antispam: 1UD129KBjvJXoWrury8JF48Xr4xAr4rtr43Wrg_yoW8JF17p3 sIg34kWr93W34q9F4Ik3W7X3W7t3Z8Gr4UGF4akr12vrW5Wrs2gF1jy3WFgF4UtrZxG390 qF1UWry7A3WUCa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmF14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI 8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwAC jcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka0x kIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1V AY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAI cVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIx AIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2 KfnxnUUI43ZEXa7VUbpwZ7UUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi ext4_load_tail_bh() ignores the return value of ext4_get_block(), so an I/O or allocation failure is silently discarded. buffer_mapped(bh) stays false and the function returns NULL, which callers such as ext4_block_do_zero_range() treat as "nothing to do" and return success. This can mask real failures during zero-range, truncate, or punch-hole operations, potentially exposing stale data if the block was not actually a hole and needed zeroing. So propagate the error to the callers. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/inode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 3ce925ca0769..77ec82fbda89 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4064,7 +4064,9 @@ static struct buffer_head *ext4_load_tail_bh(struct i= node *inode, loff_t from) } if (!buffer_mapped(bh)) { BUFFER_TRACE(bh, "unmapped"); - ext4_get_block(inode, iblock, bh, 0); + err =3D ext4_get_block(inode, iblock, bh, 0); + if (err < 0) + goto unlock; /* unmapped? It's a hole - nothing to do */ if (!buffer_mapped(bh)) { BUFFER_TRACE(bh, "still unmapped"); --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 656F23F5BF1; Tue, 14 Jul 2026 08:09:12 +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=1784016555; cv=none; b=ksKCrz57kGDm3yBLxaE4uW0bbbQg5gzgqreRBqX3oHT9bObzWuBUsdY9kTWlIXBOdjGSRSC5D6GdQczR3zygshMKc9VT2PfB9M+85O/ij0tTvNukwQ7ji63IrloxuJPRup3JUcOJNvrJ+xRspEvop8Uv5vxV1bNswXHImqa0Dms= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016555; c=relaxed/simple; bh=er5gSXh4WoEeObr+y+xU144WDRdSn80S3L1zLSycrGA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=T6+VKPKn0FsiZ6jwDDBJ2xkgbefnGBG88AeLge+tJKE29PiBdtw/bHTsRuqkK+afFAQCAt3c8PjXDm9lYVeNkZOJDw8W2iDmxodnPiwRi+uKsqhZiXRoE0tr98MNXKP2wqik7g9dJF2BW6pukqXjs75+P93UnTIhnhuZqFbbbmw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gzsQ92sHVzYQtm1; Tue, 14 Jul 2026 16:08:49 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 613564056E; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S8; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 4/9] ext4: move partial block zeroing earlier in ext4_zero_range() Date: Tue, 14 Jul 2026 16:00:39 +0800 Message-ID: <20260714080044.4038124-5-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S8 X-Coremail-Antispam: 1UD129KBjvJXoW7uFy3uF4fGFyUGry3ur1kuFg_yoW8CF4fp3 93XF13Kr4fWry5uFWIkF15Zw4Yk3Z7GF4UGrWagr1jva9xXryfKFs0kF10gF40qrZ7AayU ZF4Yy347Kr45uaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUma14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr 1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE 3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2I x0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8 JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2 ka0xkIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Y z7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zV AF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4l IxAIcVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsG vfC2KfnxnUUI43ZEXa7VUbPC7UUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi In ext4_zero_range(), move the ext4_zero_partial_blocks() call, which handles unaligned edges, into the same branch where the unaligned range is preallocated, immediately after ext4_alloc_file_blocks(). This is safe because there is no dependency between partial block handling and the subsequent full block handling. This change will be used by later patches that handle unaligned FALLOC_FL_WRITE_ZEROES operations, which will need to check the partial zeroed result. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/extents.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 125f628e738a..27ca641e701b 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4734,10 +4734,16 @@ static long ext4_zero_range(struct file *file, loff= _t offset, } =20 flags =3D EXT4_GET_BLOCKS_CREATE_UNWRIT_EXT; - /* Preallocate the range including the unaligned edges */ + /* + * Preallocate the range including the unaligned edges, and zero + * out partial blocks if they already contain data. + */ if (!IS_ALIGNED(offset | end, blocksize)) { ret =3D ext4_alloc_file_blocks(file, offset, len, new_size, flags); + if (!ret) + ret =3D ext4_zero_partial_blocks(inode, offset, len, + &partial_zeroed); if (ret) return ret; } @@ -4770,10 +4776,6 @@ static long ext4_zero_range(struct file *file, loff_= t offset, if (IS_ALIGNED(offset | end, blocksize)) return ret; =20 - /* Zero out partial block at the edges of the range */ - ret =3D ext4_zero_partial_blocks(inode, offset, len, &partial_zeroed); - if (ret) - return ret; if (((file->f_flags & O_SYNC) || IS_SYNC(inode)) && partial_zeroed) { ret =3D filemap_write_and_wait_range(inode->i_mapping, offset, end - 1); --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 535E23F5BE5; Tue, 14 Jul 2026 08:09:12 +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=1784016554; cv=none; b=q06S2LkvKVXmOjGwo9JtR7JAneNJLeIlcSbloMnxlS9mtFhnLYtfyCH9j6FAemADnDa1/Esu/ELp7Jc1loZ8kNggQZFNNYSqRB9qmmkG5b2+3Arq4NSjcS0HbfYr31BDyazoXo5rE7Xr+eolDXzaoLA125KONHNU66KrmAm1Ys4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016554; c=relaxed/simple; bh=cJzYjg+TKxGpl1RWyKyr/JXSx96psFme5BQTN6TaH+E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eOhO+FA/qhuyFXdw/iia6vVSjFRepyUfJn1IHQGks/sFpGzt1xzPdT5QuGlrxdpnG1UjZBVUqBIB1SSRvQ7AnERG5lfKkWs+C1F2MeG8Bj34VIYkYJOLOr+hXyNMMwvj1NkwU0Ee2JcfRvrPF4sGtYJlZdM4C2luZqYHz6CGRHQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gzsQ93Zn8zYQtlS; Tue, 14 Jul 2026 16:08:49 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 7AF334056E; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S9; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 5/9] ext4: clarify return semantics of ext4_load_tail_bh() Date: Tue, 14 Jul 2026 16:00:40 +0800 Message-ID: <20260714080044.4038124-6-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S9 X-Coremail-Antispam: 1UD129KBjvJXoW7ZF43ZF1kuF1xAr4Utr4rAFb_yoW8ZFyrpa sIgasFgrWrWas7uayIq3W7Xr1rtasrGr4UWayrK3W2va45Wr4SvF1qyFyS9F4jyrWfGrWY qFWUKry3Gan8A3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl 6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_ Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8c xan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1I6r4U MIIF0xvE2Ix0cI8IcVCY1x0267AKxVWxJVW8Jr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r 1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi ext4_load_tail_bh() returns NULL for both holes and clean unwritten buffers, but the conditions that lead to this are not obvious from the code alone. Document this behavior to clarify the return value, so that readers do not mistakenly assume that only holes result in a NULL return. Also update the inline comment following the ext4_get_block() call to reflect this, and note that a lookup-only get_block (without EXT4_GET_BLOCKS_CREATE) never sets BH_Mapped for clean unwritten extents, which is why a clean unwritten bh falls through to the "nothing to do" path. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/inode.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 77ec82fbda89..479ed73b5cda 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4026,6 +4026,10 @@ void ext4_set_aops(struct inode *inode) * because it might have data in pagecache (eg, if called from ext4_zero_r= ange, * ext4_punch_hole, etc) which needs to be properly zeroed out. Otherwise a * racing writeback can come later and flush the stale pagecache to disk. + * + * Return the loaded bh if it actually needs zeroing - in written, dirty + * unwritten, or delalloc state. Return NULL if it's clean (i.e., a hole or + * a clean unwritten block). */ static struct buffer_head *ext4_load_tail_bh(struct inode *inode, loff_t f= rom) { @@ -4067,7 +4071,12 @@ static struct buffer_head *ext4_load_tail_bh(struct = inode *inode, loff_t from) err =3D ext4_get_block(inode, iblock, bh, 0); if (err < 0) goto unlock; - /* unmapped? It's a hole - nothing to do */ + /* + * It's a hole or a clean unwritten block - nothing to do. + * Note that a lookup-only get_block (without + * EXT4_GET_BLOCKS_CREATE) never sets BH_Mapped for clean + * unwritten extents. + */ if (!buffer_mapped(bh)) { BUFFER_TRACE(bh, "still unmapped"); goto unlock; --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EEB4257435; Tue, 14 Jul 2026 08:09:12 +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=1784016555; cv=none; b=N4MQ/exbrTL7YcTtr756LAF4c2ZHldzdGcOSzNYCRC5qronGNqVreoL/8azhegtdsuqdQVZrohjz2O3uXY5wh1156gNNDKZYZUNOox8WJeng+gaNC1MUbo7AYERK/dxNUc2iXDZan+pIQo+g6VrCPvepWEM06UrTsPB2FZGsiyI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016555; c=relaxed/simple; bh=wq6srPQ0Q+eYWwwXCdktrtce+86VyBk+wEdy4pzBy+E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZJ5v11ReXT6Z2wY8u+mvQOeu7WMmw3av2fl+PFf1/XDG7kx0ffQ7vUYXiQSPbpSWX0HgfKMhOixWNh0jJmk0lKyiatXV0psuTzr8gQzPh2MlkzcvO/E7bBHV8E7KPR8xn/eiaE1EzEAnGCLufld4Rch7molXT5AuQ6hsv6+EQKI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gzsQ94cp1zYQtlS; Tue, 14 Jul 2026 16:08:49 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 9BA5B4056D; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S10; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 6/9] ext4: track partial-zero outcome per edge in ext4_zero_partial_blocks() Date: Tue, 14 Jul 2026 16:00:41 +0800 Message-ID: <20260714080044.4038124-7-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S10 X-Coremail-Antispam: 1UD129KBjvJXoWxZw4kJF13Aw1fCr4kZw1UJrb_yoWrtFy5p3 47Ja43Gr43W348urWfGF4avw1Yy3Z3WF4kWry3Gr15ZayfXw1xKF1DKr1FvF1jgrW3Ca40 vF1Yy347Kr13CaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmv14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl 6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_ Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8c xan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1I6r4U MIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJV WUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUv cSsGvfC2KfnxnUUI43ZEXa7VUbPC7UUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Replace the single bool did_zero output of ext4_zero_partial_blocks() with a bitmask that records which edge (start, end, or both in the single-block case) was actually partial-zeroed. This allows callers to distinguish which edges have been zeroed, preparing for unaligned FALLOC_FL_WRITE_ZEROES handling in later patches. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/ext4.h | 5 ++++- fs/ext4/extents.c | 2 +- fs/ext4/inode.c | 36 ++++++++++++++++++++++++++++++------ 3 files changed, 35 insertions(+), 8 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 94283a991e5c..b2e55876d0e3 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -3099,8 +3099,11 @@ extern int ext4_chunk_trans_extent(struct inode *ino= de, int nrblocks); extern int ext4_meta_trans_blocks(struct inode *inode, int lblocks, int pextents); extern int ext4_block_zero_eof(struct inode *inode, loff_t from, loff_t en= d); + +#define EXT4_PARTIAL_ZERO_START 0x1 +#define EXT4_PARTIAL_ZERO_END 0x2 extern int ext4_zero_partial_blocks(struct inode *inode, loff_t lstart, - loff_t length, bool *did_zero); + loff_t length, unsigned int *partial_zeroed); extern vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf); extern qsize_t *ext4_get_reserved_space(struct inode *inode); extern int ext4_get_projid(struct inode *inode, kprojid_t *projid); diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 27ca641e701b..7a8f9f188a29 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4715,7 +4715,7 @@ static long ext4_zero_range(struct file *file, loff_t= offset, loff_t align_start, align_end, new_size =3D 0; loff_t end =3D offset + len; unsigned int blocksize =3D i_blocksize(inode); - bool partial_zeroed =3D false; + unsigned int partial_zeroed =3D 0; int ret, flags; =20 trace_ext4_zero_range(inode, offset, len, mode); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 479ed73b5cda..a1615084a3b9 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4271,13 +4271,26 @@ int ext4_block_zero_eof(struct inode *inode, loff_t= from, loff_t end) return 0; } =20 +/* + * Zero out the unaligned head and tail of the [lstart, lstart+length) + * range. + * + * On return, @partial_zeroed records which edges actually got + * partial-zeroed. Set EXT4_PARTIAL_ZERO_START/EXT4_PARTIAL_ZERO_END if + * the head/tail block got actually partially zeroed (in written, dirty + * unwritten or delalloc state). Cleared if the head/tail block is a + * hole or a clean unwritten block, in which case there is nothing that + * needs zeroing. When the head and tail land in the same block, both + * bits are set together on a successful zeroing. + */ int ext4_zero_partial_blocks(struct inode *inode, loff_t lstart, loff_t le= ngth, - bool *did_zero) + unsigned int *partial_zeroed) { struct super_block *sb =3D inode->i_sb; unsigned partial_start, partial_end; ext4_fsblk_t start, end; loff_t byte_end =3D (lstart + length - 1); + bool did_zero =3D false; int err =3D 0; =20 partial_start =3D lstart & (sb->s_blocksize - 1); @@ -4289,21 +4302,32 @@ int ext4_zero_partial_blocks(struct inode *inode, l= off_t lstart, loff_t length, /* Handle partial zero within the single block */ if (start =3D=3D end && (partial_start || (partial_end !=3D sb->s_blocksize - 1))) { - err =3D ext4_block_zero_range(inode, lstart, length, did_zero, + err =3D ext4_block_zero_range(inode, lstart, length, &did_zero, NULL); + if (did_zero) + *partial_zeroed |=3D (EXT4_PARTIAL_ZERO_START | + EXT4_PARTIAL_ZERO_END); return err; } /* Handle partial zero out on the start of the range */ if (partial_start) { err =3D ext4_block_zero_range(inode, lstart, sb->s_blocksize, - did_zero, NULL); + &did_zero, NULL); if (err) return err; + if (did_zero) + *partial_zeroed |=3D EXT4_PARTIAL_ZERO_START; } /* Handle partial zero out on the end of the range */ - if (partial_end !=3D sb->s_blocksize - 1) + if (partial_end !=3D sb->s_blocksize - 1) { + did_zero =3D false; err =3D ext4_block_zero_range(inode, byte_end - partial_end, - partial_end + 1, did_zero, NULL); + partial_end + 1, &did_zero, NULL); + if (err) + return err; + if (did_zero) + *partial_zeroed |=3D EXT4_PARTIAL_ZERO_END; + } return err; } =20 @@ -4452,7 +4476,7 @@ int ext4_punch_hole(struct file *file, loff_t offset,= loff_t length) loff_t end =3D offset + length; handle_t *handle; unsigned int credits; - bool partial_zeroed =3D false; + unsigned int partial_zeroed =3D 0; int ret; =20 trace_ext4_punch_hole(inode, offset, length, 0); --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 534A33F5BDB; Tue, 14 Jul 2026 08:09:12 +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=1784016556; cv=none; b=gnONS+RN746yMiCb7bhls/VFkV25sRY3pqPQ2LOuRFiTHX+G8I8sJDS08k+2Cq+5BxVSXAcTfjJCKqtDZFpDmE0bI73m5PFWCBE2y73Vpaw+IU+iQ7y0WFWv0yiUJMl45AGSRNbOWS+3JVcsk9pjvKah2jwlsSfkZTRPWI8BiT8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016556; c=relaxed/simple; bh=IsYsRytYkqZ3+jxKCe+k71IS8frjxQzpaBZCnCPGvME=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QxGipwILXG87lY4OBvmjCkrkIb7ka0rSifm00mo5P3VkI2yFH3h64lweJQlgNrnu3gDvwUPe4zWVYjjOsoukI+VBb1CbaJz2f1QNtIUzcWz9Od8MuD9bCMEvQmu5uUMbNBEQBYAr4uhlvBNAzjSBKh6e3QXjGgeeXTcX2Mzpyb4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=none smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gzsQ95J2szYQtl1; Tue, 14 Jul 2026 16:08:49 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id AF1294058F; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S11; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 7/9] ext4: zero out whole block for clean edges in WRITE_ZEROES Date: Tue, 14 Jul 2026 16:00:42 +0800 Message-ID: <20260714080044.4038124-8-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S11 X-Coremail-Antispam: 1UD129KBjvJXoW7ur4kury7tr43Ar4rZrykAFb_yoW8tryUpa y7Jrn8KFW5W347ua4S93W8u3W0kwn5GF43Ar42gr4jvay3JF1fGFyqgF1UWFWY9FWfCa98 ZFsxtr1jgw1Yka7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmv14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl 6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_ Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8c xan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1I6r4U MIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJV WUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUv cSsGvfC2KfnxnUUI43ZEXa7VUbPC7UUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi FALLOC_FL_WRITE_ZEROES requires that all blocks in the requested range end up as written extents with zeroed content. For unaligned edges that were already allocated, ext4_zero_partial_blocks() zeros them directly. However, for unaligned edges whose underlying extent is a clean unwritten extent or a hole, the extent type remains unwritten after partial zeroing, which does not align with the semantics of WRITE_ZEROES. Therefore, when ext4_zero_partial_blocks() skips partial zeroing, it indicates that the corresponding edges are clean unwritten extents or holes. In this case, we need to expand the aligned allocation range outward to cover such edges, so that ext4_alloc_file_blocks() can correctly allocate blocks for the unaligned range. Edges that were partial-zeroed (i.e., written or dirty) are left untouched. Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/extents.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 7a8f9f188a29..c34505765521 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4760,6 +4760,21 @@ static long ext4_zero_range(struct file *file, loff_= t offset, /* Zero range excluding the unaligned edges */ align_start =3D round_up(offset, blocksize); align_end =3D round_down(end, blocksize); + + /* + * In WRITE_ZEROES mode, edges that were not partial-zeroed (clean + * unwritten or hole) must be allocated and zeroed as whole blocks. + * Expand the aligned range outward to cover them. + */ + if (mode & FALLOC_FL_WRITE_ZEROES) { + if (!IS_ALIGNED(offset, blocksize) && + !(partial_zeroed & EXT4_PARTIAL_ZERO_START)) + align_start =3D round_down(offset, blocksize); + if (!IS_ALIGNED(end, blocksize) && + !(partial_zeroed & EXT4_PARTIAL_ZERO_END)) + align_end =3D round_up(end, blocksize); + } + if (align_end > align_start) { if (mode & FALLOC_FL_WRITE_ZEROES) flags =3D EXT4_GET_BLOCKS_CREATE_ZERO | EXT4_EX_NOCACHE; --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04BBB3F65FC; Tue, 14 Jul 2026 08:09:16 +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=1784016559; cv=none; b=cbErVJN1RyzKYeM85yWDiivnXN2f3wFb9A34cuCa6IEW+uzriqhba1ac2akNTKYWhBMochu4X7Yv9KKbWej3Zdd770atjqswyQ1zvE3mHsquZawFzg/Q92PrSM2queGWLH4Ro4g1A7kv6vSTeB7KnA2KRF+3h0ZlaPU19SL9jhs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016559; c=relaxed/simple; bh=gi0hgWFkKIc5QLNT/ucok7g/HdEgmfTQbnGEoSB45/k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kZJ6tT69hfXV564FgQtHsDwVsVSYfDTeKQ2sJt6lWzSFYnV0FMpfWTBhzQXD3he7cH0V4NidrN7ZwJFVIgEy2dYeHpfLkAkymy3QIuH1oE/rBpceZ7xVsp8Q8eyemfJZza4O5cbt3GpAPe88BUfFlcIRGlmA5IdbH3LE+lCHghQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gzsQ960c1zYQtm6; Tue, 14 Jul 2026 16:08:49 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id C7B4C40590; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S12; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 8/9] ext4: write back partial-zeroed edges in WRITE_ZEROES Date: Tue, 14 Jul 2026 16:00:43 +0800 Message-ID: <20260714080044.4038124-9-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S12 X-Coremail-Antispam: 1UD129KBjvJXoW7ur4kury7GrWkKw18WrWxJFb_yoW8AF48pa y3Gr1UKrWUW3y7u393CF1093Wqk3Z3GrW7CrW3Gw4jvay5Xr15KFyjgF1jgF10gFWrC3y8 ZFsxK345Kr43Aa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmv14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl 6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_ Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8c xan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1I6r4U MIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJV WUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUv cSsGvfC2KfnxnUUI43ZEXa7VUbPC7UUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi FALLOC_FL_WRITE_ZEROES requires that all blocks in the requested range end up as written extents with zeroed content. For unaligned edges that were partial-zeroed in dirty unwritten or delalloc state, the buffer is left dirty while the underlying extent may not yet be converted to written. As a result, a subsequent SYNC write to this range would still trigger metadata changes, which violates the semantics of WRITE_ZEROES. Fix this by calling filemap_write_and_wait_range() for partial-zeroed edges to flush out the zeroed data and ensure the extent conversion is complete. Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- 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 c34505765521..c083703bf704 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4791,7 +4791,15 @@ static long ext4_zero_range(struct file *file, loff_= t offset, if (IS_ALIGNED(offset | end, blocksize)) return ret; =20 - if (((file->f_flags & O_SYNC) || IS_SYNC(inode)) && partial_zeroed) { + /* + * In FALLOC_FL_WRITE_ZEROES mode, edges that have been partially + * zeroed must be written back to ensure the entire zeroed range + * is converted to the written state. In SYNC mode, writeback is + * also required to persist the zeroed data to disk. + */ + if (partial_zeroed && + ((mode & FALLOC_FL_WRITE_ZEROES) || + (file->f_flags & O_SYNC) || IS_SYNC(inode))) { ret =3D filemap_write_and_wait_range(inode->i_mapping, offset, end - 1); if (ret) --=20 2.52.0 From nobody Sat Jul 25 20:08:04 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 884BA3F5BF3; Tue, 14 Jul 2026 08:09:12 +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=1784016556; cv=none; b=JmBWhqvdqiAWwaZV4/H1gJwXFr3h+oiiq3FZqzGd275NeIlEc28iTkPWx7q7iBIg8/AOmAxRWW09KeAqrJjJo6DpD0oLO5n5lT7yAYIZaYnNIrLZomJfsDU+2vS/gEsJaCWRCujPnSZc9XMhr15Db3Dlsk2l6+KAw7rywzjDYsE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784016556; c=relaxed/simple; bh=6BVhdFSrgu2Q/Sd22ZWodm4cgF2QNSJI/XEJD4+lXyU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MzL1o2R/HqdJt+xsMTp6S+nNNrcTTtzwkWsXt69fAIn5dVoEVJOeowaQBdnKlMr9u9QNI5N7pNtU7L86X+V5w34kbs1beXiywsGaffWG0Pk8l1kuAZ1bnhXNqJZFL2XIiqn0SM0XLKZqkw2FowV8OK8yX+lsek3rptiL/cUjAX0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gzsPt3lctzKHLvB; Tue, 14 Jul 2026 16:08:34 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id E359940850; Tue, 14 Jul 2026 16:09:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP1 (Coremail) with UTF8SMTPSA id cCh0CgD3B3ST7lVqDS26BA--.56424S13; Tue, 14 Jul 2026 16:09:04 +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, libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, chengzhihao1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH v4 9/9] ext4: protect WRITE_ZEROES written extents with orphan list Date: Tue, 14 Jul 2026 16:00:44 +0800 Message-ID: <20260714080044.4038124-10-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260714080044.4038124-1-yi.zhang@huaweicloud.com> References: <20260714080044.4038124-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: cCh0CgD3B3ST7lVqDS26BA--.56424S13 X-Coremail-Antispam: 1UD129KBjvJXoWxCFWfury8uFW3Xw1ktF4rAFb_yoWrXr4rpF W5Ar1rGFyrWasa9FZavF4DZF1Yk3Z7G3yUWryfW34jqan8Xr1FkFyaga4FvFWYqrWUZF4Y qr4Dt34UGa15ZrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmv14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl 6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_ Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8c xan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1I6r4U MIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJV WUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUv cSsGvfC2KfnxnUUI43ZEXa7VUbPC7UUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi In ext4_alloc_file_blocks(), the WRITE_ZEROES path converts unwritten extents to written in one transaction while i_disksize is updated to cover them only in a later transaction. A crash in between leaves written extents beyond i_disksize on disk, which fsck will complain about this. Add the inode to the orphan list in the same handle that does the conversion, and remove it once i_disksize has caught up. Fold ext4_convert_unwritten_extents() into the same handle so the orphan add and the conversion are atomic. Also add a check before conversion to ensure the conversion does not extend beyond the end of the file. Reported-by: Jan Kara Closes: https://lore.kernel.org/linux-ext4/3f6ao5amv7glbgigndtegcucgo3n34ij= 3lau6l3da3hgdxgn3v@ev66wv3r5umt/ Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara --- fs/ext4/extents.c | 45 +++++++++++++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 6 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index c083703bf704..9a1b06c8dd97 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4585,6 +4585,7 @@ static int ext4_alloc_file_blocks(struct file *file, = loff_t offset, loff_t len, loff_t epos =3D 0, old_size =3D i_size_read(inode); unsigned int blkbits =3D inode->i_blkbits; bool alloc_zero =3D false; + bool orphan =3D false; =20 BUG_ON(!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)); map.m_lblk =3D offset >> blkbits; @@ -4659,12 +4660,35 @@ static int ext4_alloc_file_blocks(struct file *file= , loff_t offset, loff_t len, =20 if (alloc_zero && (map.m_flags & (EXT4_MAP_MAPPED | EXT4_MAP_UNWRITTEN))) { + WARN_ON_ONCE(map.m_lblk + map.m_len > + EXT4_B_TO_LBLK(inode, new_size ?: old_size)); + ret =3D ext4_issue_zeroout(inode, map.m_lblk, map.m_pblk, map.m_len); - if (likely(!ret)) - ret =3D ext4_convert_unwritten_extents(NULL, + if (unlikely(ret)) + break; + + handle =3D ext4_journal_start(inode, EXT4_HT_MAP_BLOCKS, + credits); + if (IS_ERR(handle)) { + ret =3D PTR_ERR(handle); + break; + } + + if (new_size) { + ret =3D ext4_orphan_add(handle, inode); + orphan =3D true; + if (ret) { + ext4_journal_stop(handle); + break; + } + } + + ret =3D ext4_convert_unwritten_extents(handle, inode, (loff_t)map.m_lblk << blkbits, (loff_t)map.m_len << blkbits); + ret2 =3D ext4_journal_stop(handle); + ret =3D ret ? ret : ret2; if (ret) break; } @@ -4678,7 +4702,7 @@ static int ext4_alloc_file_blocks(struct file *file, = loff_t offset, loff_t len, goto retry; =20 if (!epos || !new_size) - return ret; + goto out; =20 /* * Allocate blocks, update the file size to match the size of the @@ -4687,12 +4711,16 @@ static int ext4_alloc_file_blocks(struct file *file= , loff_t offset, loff_t len, if (epos > new_size) epos =3D new_size; =20 - handle =3D ext4_journal_start(inode, EXT4_HT_MISC, 1); - if (IS_ERR(handle)) - return ret ? ret : PTR_ERR(handle); + handle =3D ext4_journal_start(inode, EXT4_HT_MISC, 2); + if (IS_ERR(handle)) { + ret =3D ret ? ret : PTR_ERR(handle); + goto out; + } =20 ext4_update_inode_size(inode, epos); ret2 =3D ext4_mark_inode_dirty(handle, inode); + if (orphan && inode->i_nlink) + ext4_orphan_del(handle, inode); ext4_update_inode_fsync_trans(handle, inode, 1); ret3 =3D ext4_journal_stop(handle); ret2 =3D ret3 ? ret3 : ret2; @@ -4701,6 +4729,11 @@ static int ext4_alloc_file_blocks(struct file *file,= loff_t offset, loff_t len, pagecache_isize_extended(inode, old_size, epos); =20 return ret ? ret : ret2; + +out: + if (orphan && inode->i_nlink) + ext4_orphan_del(NULL, inode); + return ret; } =20 static int ext4_collapse_range(struct file *file, loff_t offset, loff_t le= n); --=20 2.52.0