From: Jan Kara <jack@suse.cz>
To: Baokun Li <libaokun1@huawei.com>
Cc: linux-ext4@vger.kernel.org, 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, stable@vger.kernel.org
Subject: Re: [PATCH 3/4] ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks()
Date: Mon, 18 Dec 2023 16:14:55 +0100 [thread overview]
Message-ID: <20231218151455.yqph44iz4ihsujz5@quack3> (raw)
In-Reply-To: <20231218141814.1477338-4-libaokun1@huawei.com>
On Mon 18-12-23 22:18:13, Baokun Li wrote:
> After updating bb_free in mb_free_blocks, it is possible to return without
> updating bb_fragments because the block being freed is found to have
> already been freed, which leads to inconsistency between bb_free and
> bb_fragments.
>
> Since the group may be unlocked in ext4_grp_locked_error(), this can lead
> to problems such as dividing by zero when calculating the average fragment
> length. Therefore, to ensure consistency, move the update of bb_free to
> after the block double-free check.
>
> Fixes: eabe0444df90 ("ext4: speed-up releasing blocks on commit")
> CC: stable@vger.kernel.org # 3.10
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
I agree there's no point in updating the allocation info if the bitmap is
corrupted. We will not try to allocate (or free) blocks in that group
anymore. I'm just a bit unsure about the EXT4_FC_REPLAY state where we
don't mark the bitmap as corrupted although some blocks were already marked
as freed. So in this case the free space statistics tracking will go
permanently wrong. I'm kind of wondering in which case does fast-commit
free already freed blocks. Ted, any idea?
Honza
> ---
> fs/ext4/mballoc.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index a95fa6e2b0f9..2fbee0f0f5c3 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -1892,11 +1892,6 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
> mb_check_buddy(e4b);
> mb_free_blocks_double(inode, e4b, first, count);
>
> - this_cpu_inc(discard_pa_seq);
> - e4b->bd_info->bb_free += count;
> - if (first < e4b->bd_info->bb_first_free)
> - e4b->bd_info->bb_first_free = first;
> -
> /* access memory sequentially: check left neighbour,
> * clear range and then check right neighbour
> */
> @@ -1922,9 +1917,14 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
> sb, e4b->bd_group,
> EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> }
> - goto done;
> + return;
> }
>
> + this_cpu_inc(discard_pa_seq);
> + e4b->bd_info->bb_free += count;
> + if (first < e4b->bd_info->bb_first_free)
> + e4b->bd_info->bb_first_free = first;
> +
> /* let's maintain fragments counter */
> if (left_is_free && right_is_free)
> e4b->bd_info->bb_fragments--;
> @@ -1949,7 +1949,6 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
> if (first <= last)
> mb_buddy_mark_free(e4b, first >> 1, last >> 1);
>
> -done:
> mb_set_largest_free_order(sb, e4b->bd_info);
> mb_update_avg_fragment_size(sb, e4b->bd_info);
> mb_check_buddy(e4b);
> --
> 2.31.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-12-18 15:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 14:18 [PATCH 0/4] ext4: fix divide error in mb_update_avg_fragment_size() Baokun Li
2023-12-18 14:18 ` [PATCH 1/4] ext4: fix double-free of blocks due to wrong extents moved_len Baokun Li
2023-12-18 15:32 ` Jan Kara
2023-12-19 1:51 ` Baokun Li
2023-12-18 14:18 ` [PATCH 2/4] ext4: do not trim the group with corrupted block bitmap Baokun Li
2023-12-18 15:02 ` Jan Kara
2023-12-18 14:18 ` [PATCH 3/4] ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks() Baokun Li
2023-12-18 15:14 ` Jan Kara [this message]
2023-12-19 2:29 ` Baokun Li
2023-12-20 9:00 ` Baokun Li
2023-12-18 14:18 ` [PATCH 4/4] ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Baokun Li
2023-12-18 14:43 ` Jan Kara
2023-12-18 15:09 ` Jan Kara
2023-12-19 8:02 ` Baokun Li
2023-12-20 13:43 ` 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=20231218151455.yqph44iz4ihsujz5@quack3 \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=libaokun1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=stable@vger.kernel.org \
--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