linux-ext4 - Re: [PATCH v2] ext4: don't BUG on inconsistent journal feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200710140835.GD8447@quack2.suse.cz>
Date:   Fri, 10 Jul 2020 16:08:35 +0200
From:   Jan Kara <jack@...e.cz>
To:     Lukas Czerner <lczerner@...hat.com>
Cc:     Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2] ext4: don't BUG on inconsistent journal feature

On Fri 10-07-20 09:35:36, Lukas Czerner wrote:
> On Thu, Jul 09, 2020 at 05:41:04PM +0200, Jan Kara wrote:
> > A customer has reported a BUG_ON in ext4_clear_journal_err() hitting
> > during an LTP testing. Either this has been caused by a test setup
> > issue where the filesystem was being overwritten while LTP was mounting
> > it or the journal replay has overwritten the superblock with invalid
> > data. In either case it is preferable we don't take the machine down
> > with a BUG_ON. So handle the situation of unexpectedly missing
> > has_journal feature more gracefully. We issue warning and fail the mount
> > in the cases where the race window is narrow and the failed check is
> > most likely a programming error. In cases where fs corruption is more
> > likely, we do full ext4_error() handling before failing mount / remount.
> > 
> > Signed-off-by: Jan Kara <jack@...e.cz>
> > ---
> >  fs/ext4/super.c | 66 ++++++++++++++++++++++++++++++++++++++++-----------------
> >  1 file changed, 47 insertions(+), 19 deletions(-)
> > 
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index 330957ed1f05..2c8f74f741f4 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -66,10 +66,10 @@ static int ext4_load_journal(struct super_block *, struct ext4_super_block *,
> >  			     unsigned long journal_devnum);
> >  static int ext4_show_options(struct seq_file *seq, struct dentry *root);
> >  static int ext4_commit_super(struct super_block *sb, int sync);
> > -static void ext4_mark_recovery_complete(struct super_block *sb,
> > +static int ext4_mark_recovery_complete(struct super_block *sb,
> >  					struct ext4_super_block *es);
> > -static void ext4_clear_journal_err(struct super_block *sb,
> > -				   struct ext4_super_block *es);
> > +static int ext4_clear_journal_err(struct super_block *sb,
> > +				  struct ext4_super_block *es);
> >  static int ext4_sync_fs(struct super_block *sb, int wait);
> >  static int ext4_remount(struct super_block *sb, int *flags, char *data);
> >  static int ext4_statfs(struct dentry *dentry, struct kstatfs *buf);
> > @@ -4770,7 +4770,9 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
> >  	EXT4_SB(sb)->s_mount_state &= ~EXT4_ORPHAN_FS;
> >  	if (needs_recovery) {
> >  		ext4_msg(sb, KERN_INFO, "recovery complete");
> > -		ext4_mark_recovery_complete(sb, es);
> > +		err = ext4_mark_recovery_complete(sb, es);
> > +		if (err)
> > +			goto failed_mount8;
> 
> failed_mount8 is in #ifdef CONFIG_QUOTA so it probably needs to be moved
> out of the ifdef block.
> 
> Other than that it looks good to me, so with that change you can add
> 
> Reviewed-by: Lukas Czerner <lczerner@...hat.com>

Thanks for review! I've sent out v3 with you tag and the compilation
failure fixed up.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR