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: <CAOQ4uxhbz7=XT=C3R8XqL0K_o7KwLKsoNwgk=qJGuw2375MTJw@mail.gmail.com>
Date: Thu, 15 Jan 2026 17:07:24 +0100
From: Amir Goldstein <amir73il@...il.com>
To: André Almeida <andrealmeid@...lia.com>
Cc: Christoph Hellwig <hch@....de>, 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>, 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, 
	Qu Wenruo <wqu@...e.com>, 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 4:42 PM André Almeida <andrealmeid@...lia.com> wrote:
>
> Em 15/01/2026 04:23, Christoph Hellwig escreveu:
>
> [...]
>
> >
> > 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.
> >
>
> Yes, I'm would like to be able to mount two cloned btrfs images and to
> use overlayfs with them. This is useful for SteamOS A/B partition scheme.
>
> >> 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?
> >
>
> The Steam Deck have two main partitions to install SteamOS updates
> atomically. When you want to update the device, assuming that you are
> using partition A, the updater will write the new image in partition B,
> and vice versa. Then after the reboot, the system will mount the new
> image on B.
>

And what do you expect to happen wrt overlayfs when switching from
image A to B?

What are the origin file handles recorded in overlayfs index from image A
lower worth when the lower image is B?

Is there any guarantee that file handles are relevant and point to the
same objects?

The whole point of the overlayfs index feature is that overlayfs inodes
can have a unique id across copy-up.

Please explain in more details exactly which overlayfs setup you are
trying to do with index feature.

FWIW, the setup you are describing sounds very familiar.
I am pretty sure that a similar setup with squashfs and OpenWRT [1]
was the use case to add the uuid=off overlayfs mount options.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-unionfs/32532923.JtPX5UtSzP@fgdesktop/