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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230602151858.GA16844@frogsfrogsfrogs>
Date:   Fri, 2 Jun 2023 08:18:58 -0700
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     zhanchengbin <zhanchengbin1@...wei.com>
Cc:     tytso@....edu, linux-ext4@...r.kernel.org, linfeilong@...wei.com,
        louhongxiang@...wei.com
Subject: Re: [PATCH] e2fsck: restore sb->s_state before journal recover

On Fri, Jun 02, 2023 at 04:27:59PM +0800, zhanchengbin wrote:
> ext4_handle_error
>     EXT4_SB(sb)->s_mount_state |= EXT4_ERROR_FS;
>     if remount-ro
>         ext4_commit_super(sb);
> As you can see, when the filesystem error in the kernel, the last sb commit
> not record the journal, So sb->s_state will be overwritten by journal recover.
> In some cases , modifying metadata and superblock data are placed in two
> transactions, if the previous transaction is already in the journal, and
> ext4_handle_error occurs when updating sb, the filesystem is still error even
> if the journal is recovered(I know that this situation should not occur in
> theory, but I encountered this error when testing quota. Therefore, I think
> we cannot fully rely on the kernel).
> So when the filesystem is error before the journal recover, keep the error
> state and perform deep check later.
> 
> Signed-off-by: zhanchengbin <zhanchengbin1@...wei.com>
> ---
>  e2fsck/journal.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/e2fsck/journal.c b/e2fsck/journal.c
> index c7868d89..6f49321d 100644
> --- a/e2fsck/journal.c
> +++ b/e2fsck/journal.c
> @@ -1683,6 +1683,7 @@ errcode_t e2fsck_run_ext3_journal(e2fsck_t ctx)
>  	errcode_t	retval, recover_retval;
>  	io_stats	stats = 0;
>  	unsigned long long kbytes_written = 0;
> +	__u16 state = ctx->fs->super->s_state;
>  
>  	printf(_("%s: recovering journal\n"), ctx->device_name);
>  	if (ctx->options & E2F_OPT_READONLY) {
> @@ -1722,6 +1723,9 @@ errcode_t e2fsck_run_ext3_journal(e2fsck_t ctx)
>  	ctx->fs->flags |= EXT2_FLAG_MASTER_SB_ONLY;
>  	ctx->fs->super->s_kbytes_written += kbytes_written;
>  
> +	if (EXT2_ERROR_FS | state)

Isn't this  ^^^^^^^^^^^^^^^^^^^^^ expression always nonzero?

> +		ctx->fs->super->s_state = state | EXT2_ERROR_FS;

/me doesn't understand this bit logic at all.

--D

> +
>  	/* Set the superblock flags */
>  	e2fsck_clear_recover(ctx, recover_retval != 0);
>  
> -- 
> 2.31.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ