Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t

[Anand Suveer Jain <asj@kernel.org>]

On 12/9/26 01:23, David Sterba wrote:
> On Fri, Sep 11, 2026 at 10:51:16PM +0800, Anand Suveer Jain wrote:
>> On 11/9/26 20:32, Dave Hansen wrote:
>>> On 2/26/26 06:27, Anand Jain wrote:
>>>> Currently, f_fsid depends on fs_devices->fsid. For cloned devices, this
>>>> value is dynamic and fluctuates across mount cycles. This inconsistency
>>>> breaks persistence for subsystems like IMA.
>>>>
>>>> Switch to a stable derivation using the persistent on-disk fsuuid +
>>>> root id + devt of the block device for the single device filesystem.
>>>> This is consistent as long as the device remains unchanged/replace
>>>> (excludes btrfs device replace secnario for now).
>>>
>>> This commit evidently hit 7.2 and is causing end users some real pain.
>>> Real software uses the FSID to encrypt/decrypt their VPN key files:
>>>
>>>    https://github.com/NetworkManager/NetworkManager-openconnect/
>>>
>>> When this gets applied, those users suddenly can't connect to their VPN
>>> any more. Having a stable derivation does seem like a good idea, of
>>> course. Is there any way to make this transition without breaking
>>> existing userspace and existing users?
>>>
>>> It looks like this is also getting -stable backports.
>>
>> I wish I had more clarity on how OpenConnect uses the FSID before I
>> comment. Do you know? Can you shed some light on this?
>>
>>
>> Also, a couple of quick checks:
>>
>>  Is the underlying device MAJ:MIN changing before and after the upgrade?
>>
>>  Are the original and cloned Btrfs filesystems mounted simultaneously?
>>
>> Patch v3 (1/2) keeps the FSID persistent from the on-disk superblock and
>> stops exposing the internal random FSID. However, if OpenConnect relies
>> on statfs.f_fsid, patch v3 (2/2) now derives f_fsid from the underlying
>> MAJ:MIN.
> 
> You've sent the fsid patches [1] to fix some IMA and fanotify problems,
> so I guess there's a use case. This report shows a clear breakage in a
> different use case, I'm thinking about a quick revert as it seems to
> have worse consequences. A fix to make both work would be good but I
> can't estimate when it'll be ready so for now I'd go for a revert and
> then forward it to 7.2 stable tree.
> 
> [1] https://lore.kernel.org/linux-btrfs/cover.1772095546.git.asj@kernel.org/

Dave,

I'm currently testing the changes below, which limit the new fsid
behavior (deriving it from dev_t) strictly to cloned Btrfs.

If all goes well, I'll post the patch or will update how it goes
by EOD . Thanks!


------------
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 464129b1b0d4..ddb620ac241b 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1836,8 +1836,12 @@ static int btrfs_statfs(struct dentry *dentry,
struct kstatfs *buf)
        f_fsid.val[0] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root)
>> 32;
        f_fsid.val[1] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root);

-       /* Hash dev_t to avoid f_fsid collision with cloned filesystems. */
-       if (fs_info->fs_devices->total_devices == 1) {
+       /*
+        * Hash dev_t to avoid f_fsid collisions with cloned filesystems.
+        * Only do this when a clone is present so the original filesystem
+        * (mounted first) maintains backward-compatible f_fsid behavior.
+        */
+       if (fs_info->fs_devices->temp_fsid) {
                __kernel_fsid_t dev_fsid =

u64_to_fsid(huge_encode_dev(fs_info->fs_devices->latest_dev->bdev->bd_dev));