[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200721101802.e6xl2oewirqmxcjr@work>
Date: Tue, 21 Jul 2020 12:36:28 +0200
From: Lukas Czerner <lczerner@...hat.com>
To: Jan Kara <jack@...e.cz>
Cc: Ted Tso <tytso@....edu>, linux-ext4@...r.kernel.org,
Ritesh Harjani <riteshh@...ux.ibm.com>,
Wolfgang Frisch <wolfgang.frisch@...e.com>
Subject: Re: [PATCH 1/4] ext4: Handle error of ext4_setup_system_zone() on
remount
On Wed, Jul 15, 2020 at 03:18:09PM +0200, Jan Kara wrote:
> ext4_setup_system_zone() can fail. Handle the failure in ext4_remount().
>
> Signed-off-by: Jan Kara <jack@...e.cz>
> ---
> fs/ext4/super.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 330957ed1f05..8e055ec57a2c 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -5653,7 +5653,10 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
> ext4_register_li_request(sb, first_not_zeroed);
> }
>
> - ext4_setup_system_zone(sb);
> + err = ext4_setup_system_zone(sb);
> + if (err)
> + goto restore_opts;
> +
Thanks Jan, this looks good. But while you're at it, ext4_remount is
missing ext4_release_system_zone() and so it we want to enable block_validity
on remount and it fails after ext4_setup_system_zone() we wont release
it. This *I think* means that we would end up with block_validity
enabled without user knowing about it ?
-Lukas
> if (sbi->s_journal == NULL && !(old_sb_flags & SB_RDONLY)) {
> err = ext4_commit_super(sb, 1);
> if (err)
> --
> 2.16.4
>
Powered by blists - more mailing lists