4.19-stable patches

added patches:
	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 (file)
index 0000000..2bea932
--- /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 <wqu@suse.com>
+Date: Tue, 7 Jun 2022 19:48:24 +0800
+Subject: btrfs: reject log replay if there is unsupported RO compat flag
+
+From: Qu Wenruo <wqu@suse.com>
+
+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 <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 09e0cfbdfb9012b905c8c5d112aab4e3f4901f75..21d3ea9126a8580dedc7efdcb351aa3fe08b649d 100644 (file)
--- 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