linux-ext4 - Re: [PATCH 3/3] ext4: Add support for FS_IOC

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: <Zfi+v/9vF+mfZ4Bl@dread.disaster.area>
Date: Tue, 19 Mar 2024 09:22:55 +1100
From: Dave Chinner <david@...morbit.com>
To: "Kiselev, Oleg" <okiselev@...zon.com>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
	Theodore Ts'o <tytso@....edu>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Christian Brauner <brauner@...nel.org>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 3/3] ext4: Add support for FS_IOC_GETFSSYSFSPATH

On Mon, Mar 18, 2024 at 09:51:04PM +0000, Kiselev, Oleg wrote:
> On 3/15/24, 09:51, "Kent Overstreet" <kent.overstreet@...ux.dev <mailto:kent.overstreet@...ux.dev>> wrote:
> > On Fri, Mar 15, 2024 at 12:45:50PM -0400, Theodore Ts'o wrote:
> > > On Thu, Mar 14, 2024 at 11:53:02PM -0400, Kent Overstreet wrote:
> > > > the new sysfs path ioctl lets us get the /sys/fs/ path for a given
> > > > filesystem in a fs agnostic way, potentially nudging us towards
> > > > standarizing some of our reporting.
> > > >
> > > > --- a/fs/ext4/super.c
> > > > +++ b/fs/ext4/super.c
> > > > @@ -5346,6 +5346,7 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
> > > > sb->s_quota_types = QTYPE_MASK_USR | QTYPE_MASK_GRP | QTYPE_MASK_PRJ;
> > > > #endif
> > > > super_set_uuid(sb, es->s_uuid, sizeof(es->s_uuid));
> > > > + super_set_sysfs_name_bdev(sb);
> > >
> > > Should we perhaps be hoisting this call up to the VFS layer, so that
> > > all file systems would benefit?
> >
> >
> > I did as much hoisting as I could. For some filesystems (single device
> > filesystems) the sysfs name is the block device, for the multi device
> > filesystems I've looked at it's the UUID.
> 
> Why not use the fs UUID for all cases, single device and multi device?

Because the sysfs directory heirachy has already been defined for
many filesystems, and technically sysfs represents a KABI that we
can't just break for the hell of it.

e.g. changing everything to use uuid will break fstests
infrastructure because it assumes that it can derive the sysfs dir
location for the filesystem from the *device name* the filesystem is
mounted on. btrfs has a special implementation of that derivation
that runs the btrfs command to retreive the UUID of the filesysem.

So, yes, while we could technically change it, we break anything in
userspace that has introduced a dependency on bdev name as the sysfs
fs identifier. We're not going to break userspace like this,
especially as it is trivial to avoid.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com