[<prev] [next>] [day] [month] [year] [list]
Message-Id: <cover.1643637037.git.riteshh@linux.ibm.com>
Date: Mon, 31 Jan 2022 20:46:49 +0530
From: Ritesh Harjani <riteshh@...ux.ibm.com>
To: linux-ext4@...r.kernel.org
Cc: linux-fsdevel@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>,
Jan Kara <jack@...e.cz>,
Harshad Shirwadkar <harshadshirwadkar@...il.com>,
Ritesh Harjani <riteshh@...ux.ibm.com>
Subject: [RFC 0/6] ext4: fast_commit fixes and some minor cleanups
Hello,
Please find this small patch series which fixes one of the issue (causing data
abort exception) identified with fast_commit and flex_bg.
Although I have given -g quick, log group a run and didn't see any surprise
there. But a careful review in Patch-1 & Patch-6 will surely help! :)
Will shortly send out the fstest patch, which could trigger this.
Patch details
==============
Patch-1: Fixes a data abort which could happen during recovery with flex_bg
feature. This might be even needed to cc to stable, right?
Patch-[2-5]: Minor cleanups
Patch[6]: Good to have to avoid any accidental set/clear of critical FS Metadata
Ritesh Harjani (6):
ext4: Fixes ext4_mb_mark_bb() with flex_bg with fast_commit
ext4: Implement ext4_group_block_valid() as common function
ext4: Use in_range() for range checking in ext4_fc_replay_check_excluded
ext4: No need to test for block bitmap bits in ext4_mb_mark_bb()
ext4: Refactor ext4_free_blocks() to pull out ext4_mb_clear_bb()
ext4: Add extra check in ext4_mb_mark_bb() to prevent against possible corruption
fs/ext4/block_validity.c | 31 ++++++
fs/ext4/ext4.h | 3 +
fs/ext4/fast_commit.c | 4 +-
fs/ext4/mballoc.c | 235 +++++++++++++++++++++++----------------
4 files changed, 176 insertions(+), 97 deletions(-)
--
2.31.1
Powered by blists - more mailing lists