From nobody Thu Feb 12 00:23:54 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02D21C7619A for ; Wed, 12 Apr 2023 12:42:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231752AbjDLMm0 (ORCPT ); Wed, 12 Apr 2023 08:42:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230332AbjDLMmR (ORCPT ); Wed, 12 Apr 2023 08:42:17 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EF737AAE; Wed, 12 Apr 2023 05:42:08 -0700 (PDT) Received: from dggpeml500021.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4PxMh724xXz17Rrt; Wed, 12 Apr 2023 20:38:31 +0800 (CST) Received: from huawei.com (10.175.127.227) by dggpeml500021.china.huawei.com (7.185.36.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 12 Apr 2023 20:42:04 +0800 From: Baokun Li To: CC: , , , , , , , , Subject: [PATCH v3 3/8] ext4: use __GFP_NOFAIL if allocating extents_status cannot fail Date: Wed, 12 Apr 2023 20:41:21 +0800 Message-ID: <20230412124126.2286716-4-libaokun1@huawei.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20230412124126.2286716-1-libaokun1@huawei.com> References: <20230412124126.2286716-1-libaokun1@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500021.china.huawei.com (7.185.36.21) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" If extent status tree update fails, we have inconsistency between what is stored in the extent status tree and what is stored on disk. And that can cause even data corruption issues in some cases. For extents that cannot be dropped we use __GFP_NOFAIL to allocate memory. And with the above logic, the undo operation in __es_remove_extent that may cause inconsistency if the split extent fails is unnecessary, so we remove it as well. Suggested-by: Jan Kara Signed-off-by: Baokun Li --- V2->V3: Define helper as a preparatory patch and simplify the code. fs/ext4/extents_status.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index f9dab2510bdc..a7c3200f9cbe 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -464,10 +464,15 @@ static inline int ext4_es_must_keep(struct extent_sta= tus *es) =20 static struct extent_status * ext4_es_alloc_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t le= n, - ext4_fsblk_t pblk) + ext4_fsblk_t pblk, int nofail) { struct extent_status *es; - es =3D kmem_cache_alloc(ext4_es_cachep, GFP_ATOMIC); + gfp_t gfp_flags =3D GFP_ATOMIC; + + if (nofail) + gfp_flags |=3D __GFP_NOFAIL; + + es =3D kmem_cache_alloc(ext4_es_cachep, gfp_flags); if (es =3D=3D NULL) return NULL; es->es_lblk =3D lblk; @@ -804,7 +809,7 @@ static int __es_insert_extent(struct inode *inode, stru= ct extent_status *newes) } =20 es =3D ext4_es_alloc_extent(inode, newes->es_lblk, newes->es_len, - newes->es_pblk); + newes->es_pblk, ext4_es_must_keep(newes)); if (!es) return -ENOMEM; rb_link_node(&es->rb_node, parent, p); @@ -1361,8 +1366,6 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, ext4_es_status(&orig_es)); err =3D __es_insert_extent(inode, &newes); if (err) { - es->es_lblk =3D orig_es.es_lblk; - es->es_len =3D orig_es.es_len; if ((err =3D=3D -ENOMEM) && __es_shrink(EXT4_SB(inode->i_sb), 128, EXT4_I(inode))) --=20 2.31.1