Patch "btrfs: reject log replay if there is unsupported RO compat flag" has been added to the 5.10-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    btrfs: reject log replay if there is unsupported RO compat flag

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     btrfs-reject-log-replay-if-there-is-unsupported-ro-c.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit b6aa6ae8a77d31ad0cd39652a04d0467b60ae57d
Author: Qu Wenruo <wqu@xxxxxxxx>
Date:   Tue Jun 7 19:48:24 2022 +0800

    btrfs: reject log replay if there is unsupported RO compat flag
    
    [ Upstream commit dc4d31684974d140250f3ee612c3f0cab13b3146 ]
    
    [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@xxxxxxxxxxxxxxx #4.9+
    Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
    Reviewed-by: David Sterba <dsterba@xxxxxxxx>
    Signed-off-by: David Sterba <dsterba@xxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 35acdab56a1c..2c7e50980a70 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3104,6 +3104,20 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
 		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) {