public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Jan Tulak <jtulak@redhat.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 03/19] mkfs: Sanitise the superblock feature macros
Date: Thu, 7 Apr 2016 08:18:17 -0500	[thread overview]
Message-ID: <57065E19.9070401@sandeen.net> (raw)
In-Reply-To: <CACj3i72K0JHkGKES8eintQ=+rbN7hrSQc3+BNQ2eHfZtm7ik4g@mail.gmail.com>

On 4/7/16 8:09 AM, Jan Tulak wrote:
> 
...

> On Thu, Apr 7, 2016 at 3:43 AM, Eric Sandeen <sandeen@sandeen.net <mailto:sandeen@sandeen.net>> wrote:
> 
>     > @@ -981,11 +1077,21 @@ main(
>     >       int                     worst_freelist;
>     >       libxfs_init_t           xi;
>     >       struct fs_topology      ft;
>     > -     int                     lazy_sb_counters;
>     > -     int                     crcs_enabled;
>     > -     int                     finobt;
>     > -     bool                    finobtflag;
>     > -     int                     spinodes;
>     > +     struct sb_feat_args     sb_feat = {
>     > +             .finobt = 1,
>     > +             .finobtflag = false,
> 
> 
>     should we really have "finobtflag" in this structure?
>     This structure should only carry feature selections, not feature
>     specification flags I think.  Why is this the only such flag
>     in the structure?
> 
>     Pretty sure finobtflag should stay a variable for now
>     just like lvflag (which goes with log_version).
> 
>  
> ​It might be right to move it out​, but the flag is removed few
> patches later entirely. Is it worth of the work? I would say nah, let
> it die where it is. :-)

Given that it doesn't seem to be a bug, I guess that might be ok,
but in general introducing incorrect things and fixing them later
in the series is strongly discouraged...

>  
> 
>     ...
> 
>     > @@ -1517,7 +1617,14 @@ main(
>     >                                       c = atoi(value);
>     >                                       if (c < 0 || c > 1)
>     >                                               illegal(value, "m crc");
>     > -                                     crcs_enabled = c;
>     > +                                     if (c && nftype) {
>     > +                                             fprintf(stderr,
>     > +_("cannot specify both crc and ftype\n"));
>     > +                                             usage();
> 
>     hm, why is conflict checking added?  It's not what the commit says
>     the patch does.
> 
>     It also regresses the bug I fixed in
> 
>     commit b990de8ba4e2df2bc76a140799d3ddb4a0eac4ce
>     Author: Eric Sandeen <sandeen@sandeen.net <mailto:sandeen@sandeen.net>>
>     Date:   Tue Aug 18 17:53:17 2015 +1000
> 
>         mkfs.xfs: fix ftype-vs-crc option combination testing
> 
>     with this patch, it is broken again:
> 
>     # mkfs/mkfs.xfs -m crc=0 -n ftype=1 -dfile,name=fsfile,size=16g
>     <success>
>      # mkfs/mkfs.xfs -n ftype=1 -m crc=0 -dfile,name=fsfile,size=16g
>     cannot specify both crc and ftype
>     Usage: mkfs.xfs
>     ...
> 
> ​Because the patch is much older than your fix, and at the time it
> was created, it is possible that there wasn't any such check... I
> would call it the risk of necromancy. :-)​

Most likely a forward-port or merge error I think.

> Anyway, I already fixed this issue in this cycle, and added the the
> ftype, crc order into a test checking for options sanity. Just I
> didn't submitted the change yet.

Ok, so it is fixed in your new version of this patch?

> 
>     ...
> 
>     > @@ -1879,23 +1988,25 @@ _("32 bit Project IDs always enabled on CRC enabled filesytems\n"));
>     >       } else {
>     >               /*
>     >                * The kernel doesn't currently support crc=0,finobt=1
>     > -              * filesystems. If crcs are not enabled and the user has
>     > -              * explicitly turned them off then silently turn them off
>     > -              * to avoid an unnecessary warning. If the user explicitly
>     > -              * tried to use crc=0,finobt=1, then issue a warning before
>     > -              * turning them off.
>     > +              * filesystems. If crcs are not enabled and the user has not
>     > +              * explicitly turned finobt on, then silently turn it off to
>     > +              * avoid an unnecessary warning. If the user explicitly tried
>     > +              * to use crc=0,finobt=1, then issue a warning before turning
>     > +              * them off.
>     >                */
>     > -             if (finobt && finobtflag) {
>     > -                     fprintf(stderr,
>     > -_("warning: finobt not supported without CRC support, disabled.\n"));
>     > +             if (sb_feat.finobt){
>     > +                     if (sb_feat.finobtflag) {
>     > +                             fprintf(stderr,
>     > +     _("warning: finobt not supported without CRC support, disabled.\n"));
>     > +                     }
>     > +                     sb_feat.finobt = 0;
> 
>     like I mentioned, just this, I think (assuming we like the silent turning
>     off, but that would be a different patch):
> 
>  
> ​Merging the conditions is indeed cleaner.
> 
> And I will change it to failure, if the conflicting options are given
> explicitly. Just a small patch adding "usage();" and removing
> "warning"...​

Ok, so for this patch, nothing but the mechanical change matching all the others,
right?  If there is any change in behavior to be done, that should be a different patch.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-04-07 13:18 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-24 11:15 [PATCH 00/19] mkfs cleaning jtulak
2016-03-24 11:15 ` [PATCH 01/19] xfsprogs: use common code for multi-disk detection jtulak
2016-03-31 20:25   ` Eric Sandeen
2016-04-06  9:05     ` Jan Tulak
2016-03-24 11:15 ` [PATCH 02/19] mkfs: sanitise ftype parameter values jtulak
2016-03-24 16:33   ` Eric Sandeen
2016-03-29 16:11     ` Jan Tulak
2016-03-29 16:17       ` Eric Sandeen
2016-03-29 16:20         ` Jan Tulak
2016-03-29 17:14         ` Jan Tulak
2016-03-24 11:15 ` [PATCH 03/19] mkfs: Sanitise the superblock feature macros jtulak
2016-04-01  2:05   ` Eric Sandeen
2016-04-06  9:12     ` Jan Tulak
2016-04-06 21:01       ` Dave Chinner
2016-04-07 11:53         ` Jan Tulak
2016-04-07  0:12   ` Eric Sandeen
2016-04-07  1:43   ` Eric Sandeen
2016-04-07 13:09     ` Jan Tulak
2016-04-07 13:18       ` Eric Sandeen [this message]
2016-04-07 13:27         ` Jan Tulak
2016-03-24 11:15 ` [PATCH 04/19] mkfs: validate all input values jtulak
2016-04-06 23:02   ` Eric Sandeen
2016-04-07 11:15     ` Jan Tulak
2016-03-24 11:15 ` [PATCH 05/19] mkfs: factor boolean option parsing jtulak
2016-04-07  2:48   ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 06/19] mkfs: validate logarithmic parameters sanely jtulak
2016-04-07  2:52   ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 07/19] mkfs: structify input parameter passing jtulak
2016-04-07  3:14   ` Eric Sandeen
2016-04-07 11:43     ` Jan Tulak
2016-03-24 11:15 ` [PATCH 08/19] mkfs: getbool is redundant jtulak
2016-04-07 17:25   ` Eric Sandeen
2016-04-08 10:30     ` Jan Tulak
2016-04-08 17:41       ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 09/19] mkfs: use getnum_checked for all ranged parameters jtulak
2016-04-07 19:02   ` Eric Sandeen
2016-04-08 10:47     ` Jan Tulak
2016-04-08 15:52       ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 10/19] mkfs: add respecification detection to generic parsing jtulak
2016-04-07 19:06   ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 11/19] mkfs: table based parsing for converted parameters jtulak
2016-04-07 19:08   ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 12/19] mkfs: merge getnum jtulak
2016-04-07 19:14   ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 13/19] mkfs: encode conflicts into parsing table jtulak
2016-04-07 22:40   ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 14/19] mkfs: add string options to generic parsing jtulak
2016-04-07 22:49   ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 15/19] mkfs: don't treat files as though they are block devices jtulak
2016-04-08  0:25   ` Eric Sandeen
2016-04-08  0:32     ` Eric Sandeen
2016-04-08 14:58     ` Jan Tulak
2016-04-08 15:50       ` Eric Sandeen
2016-04-08 15:56         ` Jan Tulak
2016-04-09  4:12       ` Eric Sandeen
2016-04-13 15:43         ` Jan Tulak
2016-04-14  9:49       ` Jan Tulak
2016-04-20  9:51         ` Jan Tulak
2016-04-20 13:17           ` Jan Tulak
2016-04-20 16:53             ` Eric Sandeen
2016-04-21  9:22               ` Jan Tulak
2016-03-24 11:15 ` [PATCH 16/19] mkfs: move spinodes crc check jtulak
2016-03-24 11:15 ` [PATCH 17/19] xfsprogs: disable truncating of files jtulak
2016-04-06 21:42   ` Eric Sandeen
2016-04-07  9:41     ` Jan Tulak
2016-04-08  0:09   ` Dave Chinner
2016-04-08 10:06     ` Jan Tulak
2016-04-08 23:08       ` Dave Chinner
2016-04-13 15:08         ` Jan Tulak
2016-04-13 16:17           ` Eric Sandeen
2016-04-13 16:23             ` Jan Tulak
2016-04-13 16:25               ` Eric Sandeen
2016-04-13 21:37             ` Dave Chinner
2016-04-14 12:31               ` Jan Tulak
2016-03-24 11:15 ` [PATCH 18/19] mkfs: unit conversions are case insensitive jtulak
2016-04-06 21:10   ` Eric Sandeen
2016-04-07 10:50     ` Jan Tulak
2016-04-08  0:41       ` Eric Sandeen
2016-04-08  1:03         ` Dave Chinner
2016-04-08  9:08           ` Jan Tulak
2016-04-08 15:51             ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 19/19] mkfs: add optional 'reason' for illegal_option jtulak
2016-04-06 22:23   ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2016-04-21  9:39 [PATCH 00/19 v2] mkfs cleaning Jan Tulak
2016-04-21  9:39 ` [PATCH 03/19] mkfs: Sanitise the superblock feature macros Jan Tulak
2016-05-02 23:06   ` Eric Sandeen
2016-05-04  0:48     ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57065E19.9070401@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=jtulak@redhat.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox