From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "vishal.l.verma@intel.com" <vishal.l.verma@intel.com>
Cc: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"jmoyer@redhat.com" <jmoyer@redhat.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH v4 0/6] BTT error clearing rework
Date: Tue, 1 Aug 2017 20:06:08 +0000 [thread overview]
Message-ID: <1501617398.2042.102.camel@hpe.com> (raw)
In-Reply-To: <20170801195630.GC18006@omniknight.lm.intel.com>
On Tue, 2017-08-01 at 13:56 -0600, Vishal Verma wrote:
:
>
> Hey Toshi, that is a great catch (I'm going to look at enhancing the
> unit tests too to catch this).
>
> Your patch is correct. Normally whenever we calculate a 'nsoff', we
> use that to do arena_{read,write}_bytes, and that takes care of
> adding the initial_offset. This was the first instance where we
> calculated nsoff and did something other than rw_bytes with it (i.e.
> is_bad_pmem), and therefore this nsoff needs the initial_offset
> adjustment manually..
>
> However just adding that here is inviting future bugs like this, so
> I'm going to refactor the initial_offset adjustment into some helpers
> and use those across the board. That should prevent this sort of a
> bug again.
Sounds great. Thanks Vishal!
-Toshi
WARNING: multiple messages have this Message-ID (diff)
From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "vishal.l.verma@intel.com" <vishal.l.verma@intel.com>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH v4 0/6] BTT error clearing rework
Date: Tue, 1 Aug 2017 20:06:08 +0000 [thread overview]
Message-ID: <1501617398.2042.102.camel@hpe.com> (raw)
In-Reply-To: <20170801195630.GC18006@omniknight.lm.intel.com>
On Tue, 2017-08-01 at 13:56 -0600, Vishal Verma wrote:
:
>
> Hey Toshi, that is a great catch (I'm going to look at enhancing the
> unit tests too to catch this).
>
> Your patch is correct. Normally whenever we calculate a 'nsoff', we
> use that to do arena_{read,write}_bytes, and that takes care of
> adding the initial_offset. This was the first instance where we
> calculated nsoff and did something other than rw_bytes with it (i.e.
> is_bad_pmem), and therefore this nsoff needs the initial_offset
> adjustment manually..
>
> However just adding that here is inviting future bugs like this, so
> I'm going to refactor the initial_offset adjustment into some helpers
> and use those across the board. That should prevent this sort of a
> bug again.
Sounds great. Thanks Vishal!
-Toshi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2017-08-01 20:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-26 23:35 [PATCH v4 0/6] BTT error clearing rework Vishal Verma
2017-07-26 23:35 ` Vishal Verma
2017-07-26 23:35 ` [PATCH v4 1/6] btt: fix a missed NVDIMM_IO_ATOMIC case in the write path Vishal Verma
2017-07-26 23:35 ` Vishal Verma
2017-07-26 23:35 ` [PATCH v4 2/6] btt: refactor map entry operations with macros Vishal Verma
2017-07-26 23:35 ` Vishal Verma
2017-07-26 23:35 ` [PATCH v4 3/6] btt: ensure that flags were also unchanged during a map_read Vishal Verma
2017-07-26 23:35 ` Vishal Verma
[not found] ` <20170726233546.29052-1-vishal.l.verma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-07-26 23:35 ` [PATCH v4 4/6] btt: cache sector_size in arena_info Vishal Verma
2017-07-26 23:35 ` Vishal Verma
2017-07-26 23:35 ` [PATCH v4 5/6] libnvdimm: fix potential deadlock while clearing errors Vishal Verma
2017-07-26 23:35 ` Vishal Verma
2017-07-26 23:35 ` [PATCH v4 6/6] libnvdimm, btt: rework error clearing Vishal Verma
2017-07-26 23:35 ` Vishal Verma
2017-07-31 23:15 ` [PATCH v4 0/6] BTT error clearing rework Kani, Toshimitsu
2017-07-31 23:15 ` Kani, Toshimitsu
2017-07-31 23:35 ` Verma, Vishal L
2017-07-31 23:35 ` Verma, Vishal L
2017-08-01 15:28 ` Kani, Toshimitsu
2017-08-01 15:28 ` Kani, Toshimitsu
2017-08-01 19:11 ` Kani, Toshimitsu
2017-08-01 19:11 ` Kani, Toshimitsu
[not found] ` <1501614143.2042.101.camel-ZPxbGqLxI0U@public.gmane.org>
2017-08-01 19:56 ` Vishal Verma
2017-08-01 19:56 ` Vishal Verma
2017-08-01 20:06 ` Kani, Toshimitsu [this message]
2017-08-01 20:06 ` Kani, Toshimitsu
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=1501617398.2042.102.camel@hpe.com \
--to=toshi.kani@hpe.com \
--cc=dan.j.williams@intel.com \
--cc=jmoyer@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=rafael.j.wysocki@intel.com \
--cc=vishal.l.verma@intel.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 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.