From: Mike Snitzer <snitzer@redhat.com>
To: Heinz Mauelshagen <heinzm@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
dm-devel@redhat.com, Andy Whitcroft <apw@canonical.com>,
Shaohua Li <shli@kernel.org>, Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH 1/1] dm raid: fix compat_features validation
Date: Tue, 11 Oct 2016 13:44:22 -0400 [thread overview]
Message-ID: <20161011174421.GA25738@redhat.com> (raw)
In-Reply-To: <591b9d8d-2036-2d0f-14f2-af176b5beaea@redhat.com>
On Tue, Oct 11 2016 at 11:44am -0400,
Heinz Mauelshagen <heinzm@redhat.com> wrote:
>
>
> On 10/11/2016 05:38 PM, Andy Whitcroft wrote:
> >On Tue, Oct 11, 2016 at 05:04:34PM +0200, Heinz Mauelshagen wrote:
> >>Andy,
> >>
> >>good catch.
> >>
> >>We should rather check for V190 support only in case any
> >>compat feature flags are actually set.
> >>
> >>{
> >>+ if (le32_to_cpu(sb->compat_features) &&
> >>+ le32_to_cpu(sb->compat_features) != FEATURE_FLAG_SUPPORTS_V190)
> >>{
> >> rs->ti->error = "Unable to assemble array: Unknown flag(s)
> >>in compatible feature flags";
> >> return -EINVAL;
> >> }
> >If the feature flags are single bit combinations then I believe the
> >below does check exactly that. Checking for no 1s outside of the
> >expected features, caring not for the value of the valid bits:
> >
> >+ if (le32_to_cpu(sb->compat_features) & ~(FEATURE_FLAG_SUPPORTS_V190)) {
> >
> >with the possibilty to or in additional feature bits as they are added.
>
> Thanks,
> I prefer this to be easier readable.
Readable or not, the code with the != is _not_ future-proof. Whereas
Andy's solution is. If/when a new compat feature comes along then
FEATURE_FLAG_SUPPORTS_V190 would be replaced to be a macro that ORs all
the new compat features together (e.g. FEATURE_FLAG_COMPAT). E.g. how
dm-thin-metadata.c:__check_incompat_features() does.
We can go with the != code for now, since any future changes would
likely cause this test to be changed. Or we could fix it now _for
real_.
Mike
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Heinz Mauelshagen <heinzm@redhat.com>
Cc: Andy Whitcroft <apw@canonical.com>,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
dm-devel@redhat.com, Shaohua Li <shli@kernel.org>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH 1/1] dm raid: fix compat_features validation
Date: Tue, 11 Oct 2016 13:44:22 -0400 [thread overview]
Message-ID: <20161011174421.GA25738@redhat.com> (raw)
In-Reply-To: <591b9d8d-2036-2d0f-14f2-af176b5beaea@redhat.com>
On Tue, Oct 11 2016 at 11:44am -0400,
Heinz Mauelshagen <heinzm@redhat.com> wrote:
>
>
> On 10/11/2016 05:38 PM, Andy Whitcroft wrote:
> >On Tue, Oct 11, 2016 at 05:04:34PM +0200, Heinz Mauelshagen wrote:
> >>Andy,
> >>
> >>good catch.
> >>
> >>We should rather check for V190 support only in case any
> >>compat feature flags are actually set.
> >>
> >>{
> >>+ if (le32_to_cpu(sb->compat_features) &&
> >>+ le32_to_cpu(sb->compat_features) != FEATURE_FLAG_SUPPORTS_V190)
> >>{
> >> rs->ti->error = "Unable to assemble array: Unknown flag(s)
> >>in compatible feature flags";
> >> return -EINVAL;
> >> }
> >If the feature flags are single bit combinations then I believe the
> >below does check exactly that. Checking for no 1s outside of the
> >expected features, caring not for the value of the valid bits:
> >
> >+ if (le32_to_cpu(sb->compat_features) & ~(FEATURE_FLAG_SUPPORTS_V190)) {
> >
> >with the possibilty to or in additional feature bits as they are added.
>
> Thanks,
> I prefer this to be easier readable.
Readable or not, the code with the != is _not_ future-proof. Whereas
Andy's solution is. If/when a new compat feature comes along then
FEATURE_FLAG_SUPPORTS_V190 would be replaced to be a macro that ORs all
the new compat features together (e.g. FEATURE_FLAG_COMPAT). E.g. how
dm-thin-metadata.c:__check_incompat_features() does.
We can go with the != code for now, since any future changes would
likely cause this test to be changed. Or we could fix it now _for
real_.
Mike
next prev parent reply other threads:[~2016-10-11 17:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 14:28 [PATCH 1/1] dm raid: fix compat_features validation Andy Whitcroft
2016-10-11 14:46 ` Mike Snitzer
2016-10-11 15:04 ` [dm-devel] " Heinz Mauelshagen
2016-10-11 15:38 ` Andy Whitcroft
2016-10-11 15:38 ` [dm-devel] " Andy Whitcroft
2016-10-11 15:44 ` Heinz Mauelshagen
2016-10-11 16:21 ` [PATCH 1/1 V2] " Andy Whitcroft
2016-10-11 16:21 ` Andy Whitcroft
2016-10-11 16:53 ` Heinz Mauelshagen
2016-10-11 17:44 ` Mike Snitzer [this message]
2016-10-11 17:44 ` [PATCH 1/1] " Mike Snitzer
2016-10-14 17:14 ` Heinz Mauelshagen
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=20161011174421.GA25738@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=apw@canonical.com \
--cc=dm-devel@redhat.com \
--cc=heinzm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=shli@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.