From 46b7a2de62aeae3358d175912a200354f3efea03 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 15 Aug 2022 14:13:45 +0200 Subject: [PATCH] 4.19-stable patches added patches: btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch --- ...-there-is-unsupported-ro-compat-flag.patch | 84 +++++++++++++++++++ queue-4.19/series | 1 + 2 files changed, 85 insertions(+) create mode 100644 queue-4.19/btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch diff --git a/queue-4.19/btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch b/queue-4.19/btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch new file mode 100644 index 00000000000..2bea9329cdc --- /dev/null +++ b/queue-4.19/btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch @@ -0,0 +1,84 @@ +From dc4d31684974d140250f3ee612c3f0cab13b3146 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Tue, 7 Jun 2022 19:48:24 +0800 +Subject: btrfs: reject log replay if there is unsupported RO compat flag + +From: Qu Wenruo + +commit dc4d31684974d140250f3ee612c3f0cab13b3146 upstream. + +[BUG] +If we have a btrfs image with dirty log, along with an unsupported RO +compatible flag: + +log_root 30474240 +... +compat_flags 0x0 +compat_ro_flags 0x40000003 + ( FREE_SPACE_TREE | + FREE_SPACE_TREE_VALID | + unknown flag: 0x40000000 ) + +Then even if we can only mount it RO, we will still cause metadata +update for log replay: + + BTRFS info (device dm-1): flagging fs with big metadata feature + BTRFS info (device dm-1): using free space tree + BTRFS info (device dm-1): has skinny extents + BTRFS info (device dm-1): start tree-log replay + +This is definitely against RO compact flag requirement. + +[CAUSE] +RO compact flag only forces us to do RO mount, but we will still do log +replay for plain RO mount. + +Thus this will result us to do log replay and update metadata. + +This can be very problematic for new RO compat flag, for example older +kernel can not understand v2 cache, and if we allow metadata update on +RO mount and invalidate/corrupt v2 cache. + +[FIX] +Just reject the mount unless rescue=nologreplay is provided: + + BTRFS error (device dm-1): cannot replay dirty log with unsupport optional features (0x40000000), try rescue=nologreplay instead + +We don't want to set rescue=nologreply directly, as this would make the +end user to read the old data, and cause confusion. + +Since the such case is really rare, we're mostly fine to just reject the +mount with an error message, which also includes the proper workaround. + +CC: stable@vger.kernel.org #4.9+ +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -2920,6 +2920,20 @@ int open_ctree(struct super_block *sb, + err = -EINVAL; + goto fail_alloc; + } ++ /* ++ * We have unsupported RO compat features, although RO mounted, we ++ * should not cause any metadata write, including log replay. ++ * Or we could screw up whatever the new feature requires. ++ */ ++ if (unlikely(features && btrfs_super_log_root(disk_super) && ++ !btrfs_test_opt(fs_info, NOLOGREPLAY))) { ++ btrfs_err(fs_info, ++"cannot replay dirty log with unsupported compat_ro features (0x%llx), try rescue=nologreplay", ++ features); ++ err = -EINVAL; ++ goto fail_alloc; ++ } ++ + + ret = btrfs_init_workqueues(fs_info, fs_devices); + if (ret) { diff --git a/queue-4.19/series b/queue-4.19/series index 09e0cfbdfb9..21d3ea9126a 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -204,3 +204,4 @@ dm-raid-fix-address-sanitizer-warning-in-raid_status.patch dm-writecache-set-a-default-max_writeback_jobs.patch acpi-cppc-do-not-prevent-cppc-from-working-in-the-future.patch net_sched-cls_route-remove-from-list-when-handle-is-0.patch +btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch -- 2.47.3