diff options
| author | Jan Kara <jack@suse.cz> | 2020-07-28 15:04:37 +0200 |
|---|---|---|
| committer | Theodore Ts'o <tytso@mit.edu> | 2020-08-07 20:12:37 +0200 |
| commit | 0f5bde1db174f6c471f0bd27198575719dabe3e5 (patch) | |
| tree | bf8b4e6d02df5868ce5b3d22ef172c2b22070228 /fs/ext4/block_validity.c | |
| parent | ext4: handle add_system_zone() failure in ext4_setup_system_zone() (diff) | |
| download | linux-0f5bde1db174f6c471f0bd27198575719dabe3e5.tar.xz linux-0f5bde1db174f6c471f0bd27198575719dabe3e5.zip | |
ext4: correctly restore system zone info when remount fails
When remounting filesystem fails late during remount handling and
block_validity mount option is also changed during the remount, we fail
to restore system zone information to a state matching the mount option.
This is mostly harmless, just the block validity checking will not match
the situation described by the mount option. Make sure these two are always
consistent.
Reported-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20200728130437.7804-7-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/block_validity.c')
| -rw-r--r-- | fs/ext4/block_validity.c | 8 |
1 files changed, 0 insertions, 8 deletions
diff --git a/fs/ext4/block_validity.c b/fs/ext4/block_validity.c index 2d008c1b58f2..c54ba52f2dd4 100644 --- a/fs/ext4/block_validity.c +++ b/fs/ext4/block_validity.c @@ -220,14 +220,6 @@ int ext4_setup_system_zone(struct super_block *sb) int flex_size = ext4_flex_bg_size(sbi); int ret; - if (!test_opt(sb, BLOCK_VALIDITY)) { - if (sbi->system_blks) - ext4_release_system_zone(sb); - return 0; - } - if (sbi->system_blks) - return 0; - system_blks = kzalloc(sizeof(*system_blks), GFP_KERNEL); if (!system_blks) return -ENOMEM; |