public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Baokun Li <libaokun1@huawei.com>
To: <linux-ext4@vger.kernel.org>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>, <jack@suse.cz>,
	<ritesh.list@gmail.com>, <linux-kernel@vger.kernel.org>,
	<yi.zhang@huawei.com>, <yangerkun@huawei.com>,
	<yukuai3@huawei.com>, <libaokun1@huawei.com>
Subject: [PATCH v3 3/8] ext4: use __GFP_NOFAIL if allocating extents_status cannot fail
Date: Wed, 12 Apr 2023 20:41:21 +0800	[thread overview]
Message-ID: <20230412124126.2286716-4-libaokun1@huawei.com> (raw)
In-Reply-To: <20230412124126.2286716-1-libaokun1@huawei.com>

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 <jack@suse.cz>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
---
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_status *es)
 
 static struct extent_status *
 ext4_es_alloc_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t len,
-		     ext4_fsblk_t pblk)
+		     ext4_fsblk_t pblk, int nofail)
 {
 	struct extent_status *es;
-	es = kmem_cache_alloc(ext4_es_cachep, GFP_ATOMIC);
+	gfp_t gfp_flags = GFP_ATOMIC;
+
+	if (nofail)
+		gfp_flags |= __GFP_NOFAIL;
+
+	es = kmem_cache_alloc(ext4_es_cachep, gfp_flags);
 	if (es == NULL)
 		return NULL;
 	es->es_lblk = lblk;
@@ -804,7 +809,7 @@ static int __es_insert_extent(struct inode *inode, struct extent_status *newes)
 	}
 
 	es = 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, ext4_lblk_t lblk,
 						    ext4_es_status(&orig_es));
 			err = __es_insert_extent(inode, &newes);
 			if (err) {
-				es->es_lblk = orig_es.es_lblk;
-				es->es_len = orig_es.es_len;
 				if ((err == -ENOMEM) &&
 				    __es_shrink(EXT4_SB(inode->i_sb),
 							128, EXT4_I(inode)))
-- 
2.31.1


  parent reply	other threads:[~2023-04-12 12:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12 12:41 [PATCH v3 0/8] ext4: fix WARNING in ext4_da_update_reserve_space Baokun Li
2023-04-12 12:41 ` [PATCH v3 1/8] ext4: only update i_reserved_data_blocks on successful block allocation Baokun Li
2023-04-12 18:45   ` Jan Kara
2023-04-12 12:41 ` [PATCH v3 2/8] ext4: add a new helper to check if es must be kept Baokun Li
2023-04-12 18:53   ` Jan Kara
2023-04-13  2:00     ` Baokun Li
2023-04-13 10:34       ` Jan Kara
2023-04-13 12:26         ` Baokun Li
2023-04-12 12:41 ` Baokun Li [this message]
2023-04-13 10:30   ` [PATCH v3 3/8] ext4: use __GFP_NOFAIL if allocating extents_status cannot fail Jan Kara
2023-04-24  3:45     ` Baokun Li
2023-04-12 12:41 ` [PATCH v3 4/8] ext4: make __es_remove_extent return void Baokun Li
2023-04-12 12:41 ` [PATCH v3 5/8] ext4: make ext4_es_remove_extent " Baokun Li
2023-04-12 12:41 ` [PATCH v3 6/8] ext4: make ext4_es_insert_delayed_block " Baokun Li
2023-04-12 14:19   ` kernel test robot
2023-04-13  2:36     ` Baokun Li
2023-04-12 17:24   ` kernel test robot
2023-04-12 12:41 ` [PATCH v3 7/8] ext4: make ext4_es_insert_extent " Baokun Li
2023-04-12 12:41 ` [PATCH v3 8/8] ext4: make ext4_zeroout_es " Baokun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230412124126.2286716-4-libaokun1@huawei.com \
    --to=libaokun1@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox