On Thu, 2016-04-14 at 19:40 -0700, Dan Williams wrote:
> The ACPI specification does not specify the state of data after a
> clear
> poison operation. Potential future libnvdimm bus implementations for
> other architectures also might not specify or disagree on the state
> of
> data after clear poison. Clarify why we write twice.
>
> Reported-by: Jeff Moyer <jmo...@redhat.com>
> Reported-by: Vishal Verma <vishal.l.ve...@intel.com>
> Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
> ---
> drivers/nvdimm/pmem.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Looks good, thanks!
Reviewed-by: Vishal Verma <vishal.l.ve...@intel.com>
>
> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
> index c6befaa9c708..d9a0dbc2d023 100644
> --- a/drivers/nvdimm/pmem.c
> +++ b/drivers/nvdimm/pmem.c
> @@ -86,6 +86,20 @@ static int pmem_do_bvec(struct pmem_device *pmem,
> struct page *page,
> flush_dcache_page(page);
> }
> } else {
> + /*
> + * Note that we write the data both before and after
> + * clearing poison. The write before clear poison
> + * handles situations where the latest written data
> is
> + * preserved and the clear poison operation simply
> marks
> + * the address range as valid without changing the
> data.
> + * In this case application software can assume that
> an
> + * interrupted write will either return the new good
> + * data or an error.
> + *
> + * However, if pmem_clear_poison() leaves the data
> in an
> + * indeterminate state we need to perform the write
> + * after clear poison.
> + */
> flush_dcache_page(page);
> memcpy_to_pmem(pmem_addr, mem + off, len);
> if (unlikely(bad_pmem)) {
>
