From: Greg Kroah-Hartman Date: Mon, 15 Aug 2022 12:13:32 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v5.15.61~61 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e7a0ce9ddcb44bcf4f043c702eb1a5c80ff5e954;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch --- diff --git a/queue-4.9/btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch b/queue-4.9/btrfs-reject-log-replay-if-there-is-unsupported-ro-compat-flag.patch new file mode 100644 index 00000000000..25f8706145b --- /dev/null +++ b/queue-4.9/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 +@@ -2774,6 +2774,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; ++ } ++ + + max_active = fs_info->thread_pool_size; + diff --git a/queue-4.9/series b/queue-4.9/series index 9b427de15da..0176f8e7d71 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -56,3 +56,4 @@ ext4-fix-extent-status-tree-race-in-writeback-error-recovery-path.patch ext4-correct-max_inline_xattr_value_size-computing.patch dm-raid-fix-address-sanitizer-warning-in-raid_status.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