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
Subject: Re: [PATCH v2 8/8] ext4: mark the group block bitmap as corrupted before reporting an error
Date: Thu, 4 Jan 2024 11:51:51 +0100 [thread overview]
Message-ID: <20240104105151.3c2yrg3f3efiajgv@quack3> (raw)
In-Reply-To: <20231221150558.2740823-9-libaokun1@huawei.com>
On Thu 21-12-23 23:05:58, Baokun Li wrote:
> Otherwise unlocking the group in ext4_grp_locked_error may allow other
> processes to modify the core block bitmap that is known to be corrupt.
>
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
I'm not opposed but I don't think this matters much.
ext4_grp_locked_error() unlocks the group only in errors=remount-ro case
these days and in that case we abort the journal so none of the changes
should make it to disk anyway. Anyway, in the name of defensive programming
feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
:)
Honza
> ---
> fs/ext4/mballoc.c | 23 +++++++++++------------
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index b862ca2750fd..c43eefebdaa3 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -564,14 +564,14 @@ static void mb_free_blocks_double(struct inode *inode, struct ext4_buddy *e4b,
>
> blocknr = ext4_group_first_block_no(sb, e4b->bd_group);
> blocknr += EXT4_C2B(EXT4_SB(sb), first + i);
> + ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
> + EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> ext4_grp_locked_error(sb, e4b->bd_group,
> inode ? inode->i_ino : 0,
> blocknr,
> "freeing block already freed "
> "(bit %u)",
> first + i);
> - ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
> - EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> }
> mb_clear_bit(first + i, e4b->bd_info->bb_bitmap);
> }
> @@ -1926,14 +1926,13 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
> blocknr = ext4_group_first_block_no(sb, e4b->bd_group);
> blocknr += EXT4_C2B(sbi, block);
> if (!(sbi->s_mount_state & EXT4_FC_REPLAY)) {
> + ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
> + EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> ext4_grp_locked_error(sb, e4b->bd_group,
> inode ? inode->i_ino : 0,
> blocknr,
> "freeing already freed block (bit %u); block bitmap corrupt.",
> block);
> - ext4_mark_group_bitmap_corrupted(
> - sb, e4b->bd_group,
> - EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> } else {
> mb_regenerate_buddy(e4b);
> goto check;
> @@ -2410,12 +2409,12 @@ void ext4_mb_simple_scan_group(struct ext4_allocation_context *ac,
>
> k = mb_find_next_zero_bit(buddy, max, 0);
> if (k >= max) {
> + ext4_mark_group_bitmap_corrupted(ac->ac_sb,
> + e4b->bd_group,
> + EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> ext4_grp_locked_error(ac->ac_sb, e4b->bd_group, 0, 0,
> "%d free clusters of order %d. But found 0",
> grp->bb_counters[i], i);
> - ext4_mark_group_bitmap_corrupted(ac->ac_sb,
> - e4b->bd_group,
> - EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> break;
> }
> ac->ac_found++;
> @@ -2466,12 +2465,12 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac,
> * free blocks even though group info says we
> * have free blocks
> */
> + ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
> + EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> ext4_grp_locked_error(sb, e4b->bd_group, 0, 0,
> "%d free clusters as per "
> "group info. But bitmap says 0",
> free);
> - ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
> - EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> break;
> }
>
> @@ -2497,12 +2496,12 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac,
> if (WARN_ON(ex.fe_len <= 0))
> break;
> if (free < ex.fe_len) {
> + ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
> + EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> ext4_grp_locked_error(sb, e4b->bd_group, 0, 0,
> "%d free clusters as per "
> "group info. But got %d blocks",
> free, ex.fe_len);
> - ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
> - EXT4_GROUP_INFO_BBITMAP_CORRUPT);
> /*
> * The number of free blocks differs. This mostly
> * indicate that the bitmap is corrupt. So exit
> --
> 2.31.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-01-04 10:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 15:05 [PATCH v2 0/8] ext4: fix divide error in mb_update_avg_fragment_size() Baokun Li
2023-12-21 15:05 ` [PATCH v2 1/8] ext4: fix double-free of blocks due to wrong extents moved_len Baokun Li
2024-01-04 10:27 ` Jan Kara
2023-12-21 15:05 ` [PATCH v2 2/8] ext4: do not trim the group with corrupted block bitmap Baokun Li
2023-12-21 15:05 ` [PATCH v2 3/8] ext4: regenerate buddy after block freeing failed if under fc replay Baokun Li
2024-01-04 10:33 ` Jan Kara
2024-01-04 11:31 ` Baokun Li
2023-12-21 15:05 ` [PATCH v2 4/8] ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks() Baokun Li
2024-01-04 10:42 ` Jan Kara
2024-01-04 11:43 ` Baokun Li
2023-12-21 15:05 ` [PATCH v2 5/8] ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Baokun Li
2024-01-04 10:43 ` Jan Kara
2023-12-21 15:05 ` [PATCH v2 6/8] ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Baokun Li
2024-01-04 10:45 ` Jan Kara
2023-12-21 15:05 ` [PATCH v2 7/8] ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Baokun Li
2024-01-04 10:47 ` Jan Kara
2023-12-21 15:05 ` [PATCH v2 8/8] ext4: mark the group block bitmap as corrupted before reporting an error Baokun Li
2024-01-04 10:51 ` Jan Kara [this message]
2024-01-04 12:14 ` 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=20240104105151.3c2yrg3f3efiajgv@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=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