linux-kernel - Re: [PATCH v2 3/3] xfs: quietly ignore deprecated mount options

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] [day] [month] [year] [list]

Message-ID: <20251015153702.GY6188@frogsfrogsfrogs>
Date: Wed, 15 Oct 2025 08:37:02 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Carlos Maiolino <cem@...nel.org>, linux-kernel@...r.kernel.org,
	linux-xfs@...r.kernel.org,
	Oleksandr Natalenko <oleksandr@...alenko.name>,
	Pavel Reichl <preichl@...hat.com>,
	Thorsten Leemhuis <linux@...mhuis.info>
Subject: Re: [PATCH v2 3/3] xfs: quietly ignore deprecated mount options

On Wed, Oct 15, 2025 at 10:07:54AM +0200, Vlastimil Babka wrote:
> On 10/15/25 07:04, Darrick J. Wong wrote:
> >  static const struct fs_parameter_spec xfs_fs_parameters[] = {
> > +	/*
> > +	 * These mount options were supposed to be deprecated in September 2025
> > +	 * but the deprecation warning was buggy, so not all users were
> > +	 * notified.  The deprecation is now obnoxiously loud and postponed to
> > +	 * September 2030.
> > +	 */
> 
> FWIW, this seems at odds with the subject "quietly ignore" ;)
> "loudly ignore"? ;)
> "warn about but otherwise ignore"?

Ugh, yeah, I forgot to update the subject line.

"xfs: loudly complain about defunct mount options", then.

> Also there's maybe a difference of ignoring "attr2" because it's enabled
> anyway, and ignoring "noattr2" because it's going to be enabled regardless.
> AFAIK prior to b9a176e54162f8 "noattr2" still prevented the enabling? But
> maybe it's not important. (I don't know how (no)ikeep works.)

Old filesystems will be automatically upgraded to attr2 the next time
anyone writes to an xattr structure.  After V4 is removed in 2030, xfs
won't have to deal with attr1 structures anymore, because V5 always has
attr2.

noikeep was (and still is) the default; it means that inode blocks are
deleted when they are no longer in use.

> Hypothetically someone might complaing after taking a disk out of very old
> system without attr2, booting it on 6.18 that will enable attr2, and not
> being able to use it again in the old system. (Funnily enough similar issue
> recently happened to me with btrfs from Turris 1.0 router's microSD). But
> maybe there are other things besides attr2 that can cause it anyway.
> 
> Anyway I think even in 2030 it will be the best to just keep warning instead
> of refusing to mount.

I think you're right, we should keep this forever.  It's not that big of
a deal to accumulate all the dead mount options via fsparam_dead, and
probably a good tombstone to prevent accidental reuse in the future.

--D

> > +	fsparam_dead("attr2"),
> > +	fsparam_dead("noattr2"),
> > +	fsparam_dead("ikeep"),
> > +	fsparam_dead("noikeep"),
> > +
> >  	fsparam_u32("logbufs",		Opt_logbufs),
> >  	fsparam_string("logbsize",	Opt_logbsize),
> >  	fsparam_string("logdev",	Opt_logdev),
> > @@ -1417,6 +1431,9 @@ xfs_fs_parse_param(
> >  		return opt;
> >  
> >  	switch (opt) {
> > +	case Op_deprecated:
> > +		xfs_fs_warn_deprecated(fc, param);
> > +		return 0;
> >  	case Opt_logbufs:
> >  		parsing_mp->m_logbufs = result.uint_32;
> >  		return 0;
> > @@ -1537,7 +1554,6 @@ xfs_fs_parse_param(
> >  		xfs_mount_set_dax_mode(parsing_mp, result.uint_32);
> >  		return 0;
> >  #endif
> > -	/* Following mount options will be removed in September 2025 */
> >  	case Opt_max_open_zones:
> >  		parsing_mp->m_max_open_zones = result.uint_32;
> >  		return 0;
> 
>