From: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/8] imsm: parse bad block log in metadata on startup
Date: Tue, 29 Nov 2016 14:17:21 +0100 [thread overview]
Message-ID: <20161129131721.GA31745@proton.igk.intel.com> (raw)
In-Reply-To: <wrfjh977mqnt.fsf@redhat.com>
On Wed, Nov 16, 2016 at 09:43:18AM -0500, Jes Sorensen wrote:
> Tomasz Majchrzak <tomasz.majchrzak@intel.com> writes:
> > Always allocate memory for all log entries to avoid a need for memory
> > allocation when monitor requests to record a bad block.
> >
> > Also some extra checks added to make static code analyzer happy.
> >
> > Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> > ---
> > super-intel.c | 158 +++++++++++++++++++++++++++++++++++++++++-----------------
> > 1 file changed, 112 insertions(+), 46 deletions(-)
>
> > @@ -785,6 +787,92 @@ static struct imsm_dev *get_imsm_dev(struct intel_super *super, __u8 index)
> > return NULL;
> > }
> >
> > +#if BYTE_ORDER == LITTLE_ENDIAN
> > +static inline unsigned long long __le48_to_cpu(const struct bbm_log_block_addr
> > + *addr)
> > +{
> > + return ((((__u64)addr->dw1) << 16) | addr->w1);
> > +}
> > +
> > +static inline struct bbm_log_block_addr __cpu_to_le48(unsigned long long sec)
> > +{
> > + struct bbm_log_block_addr addr;
> > +
> > + addr.w1 = (__u16)(sec & 0xFFFF);
> > + addr.dw1 = (__u32)((sec >> 16) & 0xFFFFFFFF);
> > + return addr;
> > +}
>
> Again, 0xffff/0xffffffff
>
> > +#elif BYTE_ORDER == BIG_ENDIAN
> > +static inline unsigned long long __le48_to_cpu(const struct bbm_log_block_addr
> > + *addr)
> > +{
> > + return ((((__u64)__le32_to_cpu(addr->dw1)) << 16) |
> > + __le16_to_cpu(addr->w1));
> > +}
> > +
> > +static inline struct bbm_log_block_addr __cpu_to_le48(unsigned long long sec)
> > +{
> > + struct bbm_log_block_addr addr;
> > +
> > + addr.w1 = __cpu_to_le16((__u16)(sec & 0xFFFF));
> > + addr.dw1 = __cpu_to_le32((__u32)(sec >> 16) & 0xFFFFFFFF);
> > + return addr;
> > +}
>
> Given that __cpu_to_le*()/__le*_to_cpu*() are no-ops on little-endian,
> you don't really need two versions of these. The big-endian version
> should suffice for both, which makes it far less cluttered. Unless I got
> something wrong here of course.
>
> > +#else
> > +# error "unknown endianness."
> > +#endif
> > +
Hi Jes,
Internally IMSM metadata stores bad block address as 48-bit little-endian
value. Those functions provide conversion from/to a structure consisting of
2 fields (32 + 16 bits). For little-endian CPU it's just about shifting bits,
for big-endian CPU bits have to be swapped. IMSM is not available on
big-endian platforms so big-endian implementation is provided for
completeness. I haven't changed it in my latest patch.
Regards,
Tomek
next prev parent reply other threads:[~2016-11-29 13:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-31 14:50 [PATCH 1/8] imsm: parse bad block log in metadata on startup Tomasz Majchrzak
2016-10-31 14:50 ` [PATCH 2/8] imsm: write bad block log on metadata sync Tomasz Majchrzak
2016-11-16 14:47 ` Jes Sorensen
2016-10-31 14:50 ` [PATCH 3/8] imsm: give md list of known bad blocks on startup Tomasz Majchrzak
2016-10-31 14:50 ` [PATCH 4/8] imsm: record new bad block in bad block log Tomasz Majchrzak
2016-10-31 14:50 ` [PATCH 5/8] imsm: clear bad block from " Tomasz Majchrzak
2016-10-31 14:50 ` [PATCH 6/8] imsm: clear bad blocks if disk becomes unavailable Tomasz Majchrzak
2016-10-31 14:50 ` [PATCH 7/8] imsm: provide list of bad blocks for an array Tomasz Majchrzak
2016-10-31 14:50 ` [PATCH 8/8] imsm: implement "--examine-badblocks" command Tomasz Majchrzak
2016-10-31 18:02 ` [PATCH 1/8] imsm: parse bad block log in metadata on startup Jes Sorensen
2016-11-16 14:43 ` Jes Sorensen
2016-11-29 13:17 ` Tomasz Majchrzak [this message]
2016-11-29 15:18 ` Jes Sorensen
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=20161129131721.GA31745@proton.igk.intel.com \
--to=tomasz.majchrzak@intel.com \
--cc=Jes.Sorensen@redhat.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 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.