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: <20260115072311.GA10352@lst.de>
Date: Thu, 15 Jan 2026 08:23:12 +0100
From: Christoph Hellwig <hch@....de>
To: Qu Wenruo <wqu@...e.com>
Cc: Christoph Hellwig <hch@....de>,
	André Almeida <andrealmeid@...lia.com>,
	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

On Thu, Jan 15, 2026 at 05:21:04PM +1030, Qu Wenruo wrote:
> So that means let btrfs to convert the temp fsid into metadata uuid, which 
> I think is fine.

At least in XFS terms, that metadata uuid is the persistent, never
changing uuid in the metadata headrs.

> 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).

Which is really dangerous and should not be used in normal operation.
For XFS with support it with a nouuid option, mostly for historic
reasons and to be able to change the uuid transactional using an
ioctl.

> 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.

dev_t is not related to the uuid in any way for XFS, and while I'm not
an expert there I'm pretty sure ext4 uses the same not dev related uuid
generation.

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

I still wonder what the use case is here.  Looking at André's original
mail it states:

"However, btrfs mounts may have volatiles UUIDs. When mounting the exact same
disk image with btrfs, a random UUID is assigned for the following disks each
time they are mounted, stored at temp_fsid and used across the kernel as the
disk UUID. `btrfs filesystem show` presents that. Calling statfs() however
shows the original (and duplicated) UUID for all disks."

and this doesn't even talk about multiple mounts, but looking at
device_list_add it seems to only set the temp_fsid flag when set
same_fsid_diff_dev is set by find_fsid_by_device, which isn't documented
well, but does indeed seem to be done transparently when two file systems
with the same fsid are mounted.

So André, can you confirm this what you're worried about?  And btrfs
developers, I think the main problem is indeed that btrfs simply allows
mounting the same fsid twice.  Which is really fatal for anything using
the fsid/uuid, such NFS exports, mount by fs uuid or any sb->s_uuid user.

> 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.

What's an A/B partition?  And how are these safely used at the same time?