linux-kernel - [PATCH] ext4: remove checks for data=ordered and journal_async

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-next>] [day] [month] [year] [list]

Message-Id: <20240320105808.1184826-1-ks77sj@gmail.com>
Date: Wed, 20 Mar 2024 19:58:08 +0900
From: Jongseok Kim <ks77sj@...il.com>
To: tytso@....edu,
	jack@...e.com,
	adilger.kernel@...ger.ca
Cc: linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Jongseok Kim <ks77sj@...il.com>
Subject: [PATCH] ext4: remove checks for data=ordered and journal_async_commit options

On Tue, Nov 25, 2014 at 04:56:15PM +0100, Jan Kara wrote:
> Option journal_async_commit breaks gurantees of data=ordered mode as it
> sends only a single cache flush after writing a transaction commit
> block. Thus even though the transaction including the commit block is
> fully stored on persistent storage, file data may still linger in drives
> caches and will be lost on power failure. Since all checksums match on
> journal recovery, we replay the transaction thus possibly exposing stale
> user data.
>
> To fix this data exposure issue, remove the possibility to use
> journal_async_commit in data=ordered mode.
>
> Signed-off-by: Jan Kara <jack@...e.cz>

In employing the journal_async_commit feature, the approach involves
slightly early submission of a request for a transaction commit block
without the inclusion of PREFLUSH and FUA. Instead, once all the blocks of
the transaction have been written, the journal device is flushed once.
This methodology, even under data=ordered mode, due to the procedure of
flushing the j_fs_dev, guarantees that the file data is permanently stored
by the time the commit block request is initiated.

This discussion pertains to scenarios where the file data device and
the journal device are distinct. If the devices are the same,
then all file data is written before the flush of the journal device,
making a single flush sufficient in this context.

Consequently, it remains entirely permissible to activate
the journal_async_commit option, even when operating in ordered mode.

Should my interpretation deviate in any manner,
I earnestly request your guidance and correction.

Signed-off-by: Jongseok Kim <ks77sj@...il.com>
---
 fs/ext4/super.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index cfb8449c731f..2141c2eb4bf0 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4954,13 +4954,6 @@ static int ext4_load_and_init_journal(struct super_block *sb,
 		break;
 	}

-	if (test_opt(sb, DATA_FLAGS) == EXT4_MOUNT_ORDERED_DATA &&
-	    test_opt(sb, JOURNAL_ASYNC_COMMIT)) {
-		ext4_msg(sb, KERN_ERR, "can't mount with "
-			"journal_async_commit in data=ordered mode");
-		goto out;
-	}
-
 	set_task_ioprio(sbi->s_journal->j_task, ctx->journal_ioprio);

 	sbi->s_journal->j_submit_inode_data_buffers =
@@ -6510,13 +6503,6 @@ static int __ext4_remount(struct fs_context *fc, struct super_block *sb)
 			err = -EINVAL;
 			goto restore_opts;
 		}
-	} else if (test_opt(sb, DATA_FLAGS) == EXT4_MOUNT_ORDERED_DATA) {
-		if (test_opt(sb, JOURNAL_ASYNC_COMMIT)) {
-			ext4_msg(sb, KERN_ERR, "can't mount with "
-				"journal_async_commit in data=ordered mode");
-			err = -EINVAL;
-			goto restore_opts;
-		}
 	}

 	if ((sbi->s_mount_opt ^ old_opts.s_mount_opt) & EXT4_MOUNT_NO_MBCACHE) {
-- 
2.34.1