linux-kernel - Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <633bb5f3-4582-416c-b8b9-fd1f3b3452ab@suse.com>
Date: Thu, 15 Jan 2026 17:21:04 +1030
From: Qu Wenruo <wqu@...e.com>
To: Christoph Hellwig <hch@....de>, André Almeida
 <andrealmeid@...lia.com>
Cc: Chuck Lever <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>,
 NeilBrown <neil@...wn.name>, Olga Kornievskaia <okorniev@...hat.com>,
 Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
 Carlos Maiolino <cem@...nel.org>, Amir Goldstein <amir73il@...il.com>,
 Chris Mason <clm@...com>, David Sterba <dsterba@...e.com>,
 Miklos Szeredi <miklos@...redi.hu>, Christian Brauner <brauner@...nel.org>,
 Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
 linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-btrfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
 kernel-dev@...lia.com
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

在 2026/1/15 16:59, Christoph Hellwig 写道:
> On Wed, Jan 14, 2026 at 01:17:15PM -0300, André Almeida wrote:
>> Em 14/01/2026 03:26, Christoph Hellwig escreveu:
>>> On Wed, Jan 14, 2026 at 01:31:43AM -0300, André Almeida wrote:
>>>> Some filesystem, like btrfs, supports mounting cloned images, but assign
>>>> random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
>>>> check, given that every time the same image is mounted, it get's
>>>> assigned a new UUID.
>>>
>>> ... and the fix is to not assign random uuid, but to assign a new uuid
>>> to the cloned image that is persisted.  That might need a new field
>>> to distintguish the stamped into the format uuid from the visible
>>> uuid like the xfs metauuid, but not hacks like this.
>>>
>>
>> How can I create this non random and persisting UUID? I was thinking of
>> doing some operation on top the original UUID, like a circular shift, some
>> sort of rearrangement of the original value that we can always reproduce.
>> Is this in the right direction do you think?
> 
> Just allocate an entirely new uuid?  That's what XFS did with the
> metadata uuid (persistent and stapted into all metadata headers) vs
> user visible uuid that can be changed.

So that means let btrfs to convert the temp fsid into metadata uuid, 
which I think is fine.

But the problem is that will change the fsid of the new fs, which may or 
may not be what's expected for the current temp fsid user (they really 
want two btrfs with the same fsid).

My initial idea for this problem is to let btrfs not generate a tempfsid 
automatically, but put some special flag (e.g. SINGLE_DEV compat ro 
flag) on those fses that want duplicated fsid.

Then for those SINGLE_DEV fses, disable any multi-device related 
features, and use their dev_t to distinguish different fses just like 
EXT4/XFS, without bothering the current tempfsid hack, and just return 
the same fsid.

Unfortunately that idea is not accepted and the current automatic new 
tempfsid solution is merged.

I'm wondering will that behavior (returning the same fsid) be acceptable 
for overlayfs?

If so, I think it's time to revert the behavior before it's too late.
Currently the main usage of such duplicated fsids is for Steam deck to 
maintain A/B partitions, I think they can accept a new compat_ro flag 
for that.

Thanks,
Qu