linux-kernel - Re: [PATCH 1/3] exportfs: Rename get_uuid() to get_disk

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: <CAOQ4uxjUKnD3-PHW5fOiTCeFVEvLkbVuviLAQc7tsKrN36Rm+A@mail.gmail.com>
Date: Wed, 14 Jan 2026 11:12:17 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Christoph Hellwig <hch@....de>
Cc: "Darrick J. Wong" <djwong@...nel.org>, 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>, 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 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

On Wed, Jan 14, 2026 at 7:24 AM Christoph Hellwig <hch@....de> wrote:
>
> On Tue, Jan 13, 2026 at 10:10:28PM -0800, Darrick J. Wong wrote:
> > On Wed, Jan 14, 2026 at 01:31:41AM -0300, André Almeida wrote:
> > > To make clear which UUID is being returned, rename get_uuid() to
> > > get_disk_uuid(). Expand the function documentation to note that this
> > > function can be also used for filesystem that supports cloned devices
> > > that might have different UUIDs for userspace tools, while having the
> > > same UUID for internal usage.
> >
> > I'm not sure what a "disk uuid" is -- XFS can store two of them in the
> > ondisk superblock: the admin-modifiable one that blkid reports, and the
> > secret one that's stamped in all the metadata and cannot change.
>
> It isn't.  Totally independent of the rest of the discussion, the
> get_uuid exportfs operation is not useful for anything but the original
> pNFS block layout.  Which is actually pretty broken and should be slowly
> phased out.
>
> > IIRC XFS only shares the user-visible UUID, but they're both from the
> > disk.   Also I'm not sure what a non-disk filesystem is supposed to
> > provide here?
>
> Yeah.
>

OK. I agree that "disk uuid" is not the best name, but there is a concept
here, which is a uuid that helps to identify the domain of the file handle.

In the context of overlayfs index and "origin" xattr, this is exactly what is
needed - to validate that the object's copy up source is reliable for
the generation of a unique overlayfs object id.

The domain of the file handles is invariant to brtfs clones/snapshots.
Specifically, for btrfs, file handles contain an id of the snapshot,
so the domain of btrfs file handles is logically the uuid of the root fs.

TBH, I am not sure if the file handle domain is invariant to XFS admin
change of uuid. How likely it is to get an identical file handles for two
different objects, with XFS fs which have diverged by an LVM clone?
I think it's quite likely.

Naming is hard - we could maybe use get_domain_uuid() and document
what it means.

Whether or not we should repurpose the existing get_uuid() I don't
know - that depends whether pNFS expects the same UUID from an
"xfs clone" as overlayfs would.

Thanks,
Amir.