linux-ext4 - Re: [PATCH v3 05/13] jbd2: fast-commit recovery path changes

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: <20191016173039.GE11103@mit.edu>
Date:   Wed, 16 Oct 2019 13:30:39 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Harshad Shirwadkar <harshadshirwadkar@...il.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH v3 05/13] jbd2: fast-commit recovery path changes

On Tue, Oct 01, 2019 at 12:40:54AM -0700, Harshad Shirwadkar wrote:
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 14d549445418..e0684212384d 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
>  
>  	jbd2_write_superblock(journal, write_op);
>  
> +	if (had_fast_commit)
> +		jbd2_set_feature_fast_commit(journal);
> +

Why the logic with had_fast_commit and (re-)setting the fast commit
feature flag?

This ties back to how we handle the logic around setting the fast
commit flag if requested by the file system....

> @@ -768,6 +816,8 @@ static int do_one_pass(journal_t *journal,
>  			if (err)
>  				goto failed;
>  			continue;
> +		case JBD2_FC_BLOCK:
> +			continue;

Why should a Fast Commit block ever show up in the primary part of the
journal?   It should never happen, right?

In which case, we should probably at least issue a warning, and not
just skip the block.

					- Ted