linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/7] imsm: metadata changes for PPL
Date: Tue, 29 Nov 2016 10:21:52 -0500	[thread overview]
Message-ID: <wrfj4m2qia5r.fsf@redhat.com> (raw)
In-Reply-To: <f4ded4a5-abf2-f988-f5d0-7063f5d080d1@intel.com> (Artur Paszkiewicz's message of "Tue, 29 Nov 2016 11:47:59 +0100")

Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> On 11/29/2016 12:27 AM, Jes Sorensen wrote:
>> Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
>>> @@ -189,7 +195,30 @@ struct imsm_dev {
>>>  	__u16 cache_policy;
>>>  	__u8  cng_state;
>>>  	__u8  cng_sub_state;
>>> -#define IMSM_DEV_FILLERS 10
>>> +	__u16 my_vol_raid_dev_num; /* Used in Unique volume Id for this RaidDev */
>>> +
>>> +	/* NVM_EN */
>>> +	__u8 nv_cache_mode;
>>> +	union {
>>> +		__u8 nv_cache_flags;
>>> +		struct {
>>> +		    __u8 dirty:1; /* 1 - cache is dirty, 0 - clean */
>>> +		    __u8 nvc_health:2;
>>> +		    __u8 expansion_bytes:5;
>>> +		} nvCache;
>>> +	};
>> 
>> This sets off alarm bells here - you declare a union of a u8 and a
>> matching bitfield, but do not handle bit endian bitfields. If someone
>> tried to use this on a big endian system this could get messy.
>
> Those fields are not used in the code at all, the only thing added to
> this structure that is used is 'rwh_policy'. The rest is to fill the
> gaps between IMSM format in UEFI/Windows.

Hi Artur,

I did notice the code wasn't actually used, sorry I didn't mention
that. However I would still prefer to see at least a comment in the code
indicating that this would fail on BE systems.

>>> @@ -7565,12 +7594,15 @@ mark_checkpoint:
>>>  
>>>  skip_mark_checkpoint:
>>>  	/* mark dirty / clean */
>>> -	if (dev->vol.dirty != !consistent) {
>>> +	if ((dev->vol.dirty & RAIDVOL_DIRTY) != !consistent) {
>> 
>> This part makes my head spin (to be honest, the original code did
>> too). I had to go write a small snipped of C to figure out what the
>> compiler does with !x given x > 0, since consistent can be 0, 1, and 2
>> here.
>> 
>> Basically for RAIDVOL_CLEAN and consistent = 0, and RAIDVOL_DIRTY and
>> consistent = 1 and 2, this statement triggers. Maybe I am just terrible
>> dense when it comes to reading obfuscated C, but could we change this
>> round to a construct that is a little easier to read?
>
> Yes, I admit it is confusing. Does this look better?
>
> -       if (dev->vol.dirty != !consistent) {
> +       if (((dev->vol.dirty & RAIDVOL_DIRTY) && consistent) ||
> +           (!(dev->vol.dirty & RAIDVOL_DIRTY) && !consistent)) {

This I can read without getting headache, so yes :)

Cheers,
Jes

  reply	other threads:[~2016-11-29 15:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-24 12:29 [PATCH 0/7] mdadm support for Partial Parity Log Artur Paszkiewicz
2016-11-24 12:29 ` [PATCH 1/7] imsm: metadata changes for PPL Artur Paszkiewicz
2016-11-28 23:27   ` Jes Sorensen
2016-11-29 10:47     ` Artur Paszkiewicz
2016-11-29 15:21       ` Jes Sorensen [this message]
2016-11-30  7:34         ` Artur Paszkiewicz
2016-11-24 12:29 ` [PATCH 2/7] Generic support for --rwh-policy and PPL Artur Paszkiewicz
2016-11-24 12:29 ` [PATCH 3/7] imsm: PPL support Artur Paszkiewicz
2016-11-28 23:51   ` Jes Sorensen
2016-11-29 11:02     ` Artur Paszkiewicz
2016-11-29 15:23       ` Jes Sorensen
2016-11-30  8:07         ` Artur Paszkiewicz
2016-11-30 15:40           ` Jes Sorensen
2016-11-24 12:29 ` [PATCH 4/7] super1: " Artur Paszkiewicz
2016-11-24 12:29 ` [PATCH 5/7] imsm: allow to assemble with PPL even if dirty degraded Artur Paszkiewicz
2016-11-24 12:29 ` [PATCH 6/7] Allow changing the RWH policy for a running array Artur Paszkiewicz
2016-11-24 12:29 ` [PATCH 7/7] Man page changes for --rwh-policy Artur Paszkiewicz

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=wrfj4m2qia5r.fsf@redhat.com \
    --to=jes.sorensen@redhat.com \
    --cc=artur.paszkiewicz@intel.com \
    --cc=linux-raid@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).