Qu Wenruo 2f8a6ee294 btrfs-progs: fix the conflicting super block flags ... [BUG] There is a bug report that a canceled checksum conversion (still experimental feature) resulted in unexpected super flags: csum_type 0 (crc32c) csum_size 4 csum 0x14973811 [match] bytenr 65536 flags 0x1000000001 ( WRITTEN | CHANGING_FSID_V2 ) magic _BHRfS_M [match] While for a filesystem under checksum conversion it should have either CHANGING_DATA_CSUM or CHANGING_META_CSUM. [CAUSE] It turns out that, due to btrfs-progs keeps its own extra flags inside its own ctree.h headers, not the shared uapi headers, we have conflicting super flags: kernel-shared/uapi/btrfs_tree.h:#define BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34) kernel-shared/uapi/btrfs_tree.h:#define BTRFS_SUPER_FLAG_CHANGING_FSID (1ULL << 35) kernel-shared/uapi/btrfs_tree.h:#define BTRFS_SUPER_FLAG_CHANGING_FSID_V2 (1ULL << 36) kernel-shared/ctree.h:#define BTRFS_SUPER_FLAG_CHANGING_DATA_CSUM (1ULL << 36) kernel-shared/ctree.h:#define BTRFS_SUPER_FLAG_CHANGING_META_CSUM (1ULL << 37) Note that CHANGING_FSID_V2 is conflicting with CHANGING_DATA_CSUM. [FIX] Cross port the proper updated uapi headers into btrfs-progs, and remove the definition from ctree.h. This would change the value for CHANGING_DATA_CSUM and CHANGING_META_CSUM, but considering they are experimental features, and kernel would reject them anyway, the damage is not that huge and we can accept such change before exposing it to end users. Pull-request: #810 Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>		2024-06-24 19:17:49 +02:00
..
btrfs_tree.h	btrfs-progs: fix the conflicting super block flags	2024-06-24 19:17:49 +02:00
btrfs.h	btrfs-progs: use unsigned types for bit shifts	2024-03-12 22:05:09 +01:00