From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] libnvdimm, pmem: clear poison on write
Date: Fri, 11 Mar 2016 00:39:45 +0000 [thread overview]
Message-ID: <1457656781.4525.36.camel@intel.com> (raw)
In-Reply-To: <20160308224729.16298.49406.stgit@dwillia2-desk3.jf.intel.com>
On Tue, 2016-03-08 at 14:47 -0800, Dan Williams wrote:
> If a write is directed at a known bad block perform the following:
>
> 1/ write the data
>
> 2/ send a clear poison command
>
> 3/ invalidate the poison out of the cache hierarchy
>
> Cc: <x86@kernel.org>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> arch/x86/include/asm/pmem.h | 5 +++++
> drivers/nvdimm/bus.c | 46
> +++++++++++++++++++++++++++++++++++++++++++
> drivers/nvdimm/nd.h | 2 ++
> drivers/nvdimm/pmem.c | 29 ++++++++++++++++++++++++++-
> include/linux/pmem.h | 19 ++++++++++++++++++
> 5 files changed, 100 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
> index c57fd1ea9689..bf8b35d2035a 100644
> --- a/arch/x86/include/asm/pmem.h
> +++ b/arch/x86/include/asm/pmem.h
<>
> static int pmem_do_bvec(struct pmem_device *pmem, struct page *page,
> unsigned int len, unsigned int off, int rw,
> sector_t sector)
> {
> int rc = 0;
> + bool bad_pmem = false;
> void *mem = kmap_atomic(page);
> phys_addr_t pmem_off = sector * 512 + pmem->data_offset;
> void __pmem *pmem_addr = pmem->virt_addr + pmem_off;
>
> + if (unlikely(is_bad_pmem(&pmem->bb, sector, len)))
> + bad_pmem = true;
> +
> if (rw == READ) {
> - if (unlikely(is_bad_pmem(&pmem->bb, sector, len)))
> + if (unlikely(bad_pmem))
> rc = -EIO;
> else {
> memcpy_from_pmem(mem + off, pmem_addr, len);
> @@ -81,6 +104,10 @@ static int pmem_do_bvec(struct pmem_device *pmem,
> struct page *page,
> } else {
> flush_dcache_page(page);
> memcpy_to_pmem(pmem_addr, mem + off, len);
> + if (unlikely(bad_pmem)) {
> + pmem_clear_poison(pmem, pmem_off, len);
> + memcpy_to_pmem(pmem_addr, mem + off, len);
> + }
> }
Just noticed this -- why do we memcpy_to_pmem twice in the error case?
Sh
ouldn't it be:
if (unlikely(bad_pmem))
pmem_clear_poison(pmem, pmem_off, len);
memcpy_to_pmem(pmem_addr, mem + off, len);
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Cc: "ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 3/3] libnvdimm, pmem: clear poison on write
Date: Fri, 11 Mar 2016 00:39:45 +0000 [thread overview]
Message-ID: <1457656781.4525.36.camel@intel.com> (raw)
In-Reply-To: <20160308224729.16298.49406.stgit@dwillia2-desk3.jf.intel.com>
On Tue, 2016-03-08 at 14:47 -0800, Dan Williams wrote:
> If a write is directed at a known bad block perform the following:
>
> 1/ write the data
>
> 2/ send a clear poison command
>
> 3/ invalidate the poison out of the cache hierarchy
>
> Cc: <x86@kernel.org>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> arch/x86/include/asm/pmem.h | 5 +++++
> drivers/nvdimm/bus.c | 46
> +++++++++++++++++++++++++++++++++++++++++++
> drivers/nvdimm/nd.h | 2 ++
> drivers/nvdimm/pmem.c | 29 ++++++++++++++++++++++++++-
> include/linux/pmem.h | 19 ++++++++++++++++++
> 5 files changed, 100 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
> index c57fd1ea9689..bf8b35d2035a 100644
> --- a/arch/x86/include/asm/pmem.h
> +++ b/arch/x86/include/asm/pmem.h
<>
> static int pmem_do_bvec(struct pmem_device *pmem, struct page *page,
> unsigned int len, unsigned int off, int rw,
> sector_t sector)
> {
> int rc = 0;
> + bool bad_pmem = false;
> void *mem = kmap_atomic(page);
> phys_addr_t pmem_off = sector * 512 + pmem->data_offset;
> void __pmem *pmem_addr = pmem->virt_addr + pmem_off;
>
> + if (unlikely(is_bad_pmem(&pmem->bb, sector, len)))
> + bad_pmem = true;
> +
> if (rw == READ) {
> - if (unlikely(is_bad_pmem(&pmem->bb, sector, len)))
> + if (unlikely(bad_pmem))
> rc = -EIO;
> else {
> memcpy_from_pmem(mem + off, pmem_addr, len);
> @@ -81,6 +104,10 @@ static int pmem_do_bvec(struct pmem_device *pmem,
> struct page *page,
> } else {
> flush_dcache_page(page);
> memcpy_to_pmem(pmem_addr, mem + off, len);
> + if (unlikely(bad_pmem)) {
> + pmem_clear_poison(pmem, pmem_off, len);
> + memcpy_to_pmem(pmem_addr, mem + off, len);
> + }
> }
Just noticed this -- why do we memcpy_to_pmem twice in the error case?
Sh
ouldn't it be:
if (unlikely(bad_pmem))
pmem_clear_poison(pmem, pmem_off, len);
memcpy_to_pmem(pmem_addr, mem + off, len);
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>
Cc: "ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 3/3] libnvdimm, pmem: clear poison on write
Date: Fri, 11 Mar 2016 00:39:45 +0000 [thread overview]
Message-ID: <1457656781.4525.36.camel@intel.com> (raw)
In-Reply-To: <20160308224729.16298.49406.stgit@dwillia2-desk3.jf.intel.com>
On Tue, 2016-03-08 at 14:47 -0800, Dan Williams wrote:
> If a write is directed at a known bad block perform the following:
>
> 1/ write the data
>
> 2/ send a clear poison command
>
> 3/ invalidate the poison out of the cache hierarchy
>
> Cc: <x86@kernel.org>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> arch/x86/include/asm/pmem.h | 5 +++++
> drivers/nvdimm/bus.c | 46
> +++++++++++++++++++++++++++++++++++++++++++
> drivers/nvdimm/nd.h | 2 ++
> drivers/nvdimm/pmem.c | 29 ++++++++++++++++++++++++++-
> include/linux/pmem.h | 19 ++++++++++++++++++
> 5 files changed, 100 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
> index c57fd1ea9689..bf8b35d2035a 100644
> --- a/arch/x86/include/asm/pmem.h
> +++ b/arch/x86/include/asm/pmem.h
<>
> static int pmem_do_bvec(struct pmem_device *pmem, struct page *page,
> unsigned int len, unsigned int off, int rw,
> sector_t sector)
> {
> int rc = 0;
> + bool bad_pmem = false;
> void *mem = kmap_atomic(page);
> phys_addr_t pmem_off = sector * 512 + pmem->data_offset;
> void __pmem *pmem_addr = pmem->virt_addr + pmem_off;
>
> + if (unlikely(is_bad_pmem(&pmem->bb, sector, len)))
> + bad_pmem = true;
> +
> if (rw == READ) {
> - if (unlikely(is_bad_pmem(&pmem->bb, sector, len)))
> + if (unlikely(bad_pmem))
> rc = -EIO;
> else {
> memcpy_from_pmem(mem + off, pmem_addr, len);
> @@ -81,6 +104,10 @@ static int pmem_do_bvec(struct pmem_device *pmem,
> struct page *page,
> } else {
> flush_dcache_page(page);
> memcpy_to_pmem(pmem_addr, mem + off, len);
> + if (unlikely(bad_pmem)) {
> + pmem_clear_poison(pmem, pmem_off, len);
> + memcpy_to_pmem(pmem_addr, mem + off, len);
> + }
> }
Just noticed this -- why do we memcpy_to_pmem twice in the error case?
Sh
ouldn't it be:
if (unlikely(bad_pmem))
pmem_clear_poison(pmem, pmem_off, len);
memcpy_to_pmem(pmem_addr, mem + off, len);
next prev parent reply other threads:[~2016-03-11 0:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 22:47 [PATCH 0/3] nfit, libnvdimm, pmem: clear poison support Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-08 22:47 ` [PATCH 1/3] nfit, libnvdimm: clear poison command support Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-09 23:03 ` Verma, Vishal L
2016-03-09 23:03 ` Verma, Vishal L
2016-03-09 23:03 ` Verma, Vishal L
2016-03-09 23:07 ` Dan Williams
2016-03-09 23:07 ` Dan Williams
2016-03-09 23:07 ` Dan Williams
2016-03-08 22:47 ` [PATCH 2/3] libnvdimm, pmem: fix kmap_atomic() leak in error path Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-08 22:47 ` [PATCH 3/3] libnvdimm, pmem: clear poison on write Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-08 22:47 ` Dan Williams
2016-03-11 0:39 ` Verma, Vishal L [this message]
2016-03-11 0:39 ` Verma, Vishal L
2016-03-11 0:39 ` Verma, Vishal L
2016-03-11 0:50 ` Dan Williams
2016-03-11 0:50 ` Dan Williams
2016-03-11 0:50 ` Dan Williams
2016-03-09 23:05 ` [PATCH 0/3] nfit, libnvdimm, pmem: clear poison support Verma, Vishal L
2016-03-09 23:05 ` Verma, Vishal L
2016-03-09 23:05 ` Verma, Vishal L
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=1457656781.4525.36.camel@intel.com \
--to=vishal.l.verma@intel.com \
--cc=dan.j.williams@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=x86@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.