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  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]
Date:	Wed, 29 Jun 2011 13:03:33 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Ric Wheeler <ricwheeler@...il.com>
cc:	Andreas Dilger <adilger@...ger.ca>,
	Lukas Czerner <lczerner@...hat.com>,
	linux-ext4@...r.kernel.org, tytso@....edu
Subject: Re: [PATCH] ext4: Remove some deprecated mount options

On Wed, 29 Jun 2011, Ric Wheeler wrote:

> On 06/28/2011 05:35 PM, Andreas Dilger wrote:
> > On 2011-06-28, at 9:53 AM, Lukas Czerner wrote:
> > > Remove deprecated mount options bsddf, nogrpid, sysvgroups which has
> > > been marked as deprecated since 2.6.23 and should be removed in 2.6.28.
> > > However it is not a big deal because those are defaults anyway and the
> > > options for setting their opposites still remains in kernel (however are
> > > still deprecated). Also push the kernel version to remove those leftover
> > > options further in time.
> > > 
> > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > > index 9ea71aa..a75320e 100644
> > > --- a/fs/ext4/super.c
> > > +++ b/fs/ext4/super.c
> > > @@ -1486,24 +1483,13 @@ static int parse_options(char *options, struct
> > > super_block *sb,
> > > 		args[0].to = args[0].from = NULL;
> > > 		token = match_token(p, tokens, args);
> > > 		switch (token) {
> > > -		case Opt_bsd_df:
> > > -			ext4_msg(sb, KERN_WARNING, deprecated_msg, p,
> > > "2.6.38");
> > > -			clear_opt(sb, MINIX_DF);
> > > -			break;
> > > 		case Opt_minix_df:
> > > -			ext4_msg(sb, KERN_WARNING, deprecated_msg, p,
> > > "2.6.38");
> > > +			ext4_msg(sb, KERN_WARNING, deprecated_msg, p, "3.5");
> > > 			set_opt(sb, MINIX_DF);
> > > -
> > > 			break;
> > > 		case Opt_grpid:
> > > -			ext4_msg(sb, KERN_WARNING, deprecated_msg, p,
> > > "2.6.38");
> > > +			ext4_msg(sb, KERN_WARNING, deprecated_msg, p, "3.5");
> > > 			set_opt(sb, GRPID);
> > > -
> > > -			break;
> > > -		case Opt_nogrpid:
> > > -			ext4_msg(sb, KERN_WARNING, deprecated_msg, p,
> > > "2.6.38");
> > > -			clear_opt(sb, GRPID);
> > One problem is that these options haven't been deprecated in major vendor
> > releases (e.g. 2.6.32 for RHEL6 and SLES11), which is what most people are
> > using.  I think that they should be deprecated for at least one major
> > vendor release before being removed, otherwise it is nearly the same as just
> > deleting them on some random kernel version without telling anyone.
> > 
> > I'm not sure where you got "2.6.23" and "2.6.28" from, maybe you meant
> > "2.6.33",

Oh, sure it should be 2.6.33 and 2.6.38, sorry!

> > which is unfortunately just after the cutoff for both RHEL6 and SLES11SP1.
> > 
> > 
> > Cheers, Andreas
> > 
> 
> I am not sure that I follow the concern - people who use upstream follow that,
> people who use vendor kernels get some branched version of something old.
> 
> In fact, we try hard *not* to do things in RHEL kernels that are not upstream
> first. I would be perfectly happy to drop it upstream first and then deprecate
> it in a future RHEL release.

Ric has a valid point, it does not matter that the deprecation change
did not appear in RHEL, SLES or others because it is really a distributor
decision what code from what kernel version to use and communicate
changes with their customers.

That said, I do not think there is a point in upstream waiting for
distributors to adopt some change. Especially when it is not a question
feature test coverage.

Thanks!
-Lukas

> 
> Thanks!
> 
> Ric
> 
> (and Lukas is *very* familiar with which kernel the ext4 code was lifted from
> :))
> 
> 

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists