From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ml01.01.org (Postfix) with ESMTP id F30351A2353 for ; Fri, 15 Apr 2016 09:58:21 -0700 (PDT) From: "Verma, Vishal L" Subject: Re: [PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow Date: Fri, 15 Apr 2016 16:58:20 +0000 Message-ID: <1460739500.3012.4.camel@intel.com> References: <146068804768.24085.7722589204633361307.stgit@dwillia2-desk3.jf.intel.com> In-Reply-To: <146068804768.24085.7722589204633361307.stgit@dwillia2-desk3.jf.intel.com> Content-Language: en-US Content-ID: <39A453E113C88640B3D1A80D7F3D399C@intel.com> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "Williams, Dan J" , "linux-nvdimm@lists.01.org" Cc: "linux-kernel@vger.kernel.org" List-ID: T24gVGh1LCAyMDE2LTA0LTE0IGF0IDE5OjQwIC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+ IFRoZSBBQ1BJIHNwZWNpZmljYXRpb24gZG9lcyBub3Qgc3BlY2lmeSB0aGUgc3RhdGUgb2YgZGF0 YSBhZnRlciBhDQo+IGNsZWFyDQo+IHBvaXNvbiBvcGVyYXRpb24uwqDCoFBvdGVudGlhbCBmdXR1 cmUgbGlibnZkaW1tIGJ1cyBpbXBsZW1lbnRhdGlvbnMgZm9yDQo+IG90aGVyIGFyY2hpdGVjdHVy ZXMgYWxzbyBtaWdodCBub3Qgc3BlY2lmeSBvciBkaXNhZ3JlZSBvbiB0aGUgc3RhdGUNCj4gb2YN Cj4gZGF0YSBhZnRlciBjbGVhciBwb2lzb24uwqDCoENsYXJpZnkgd2h5IHdlIHdyaXRlIHR3aWNl Lg0KPiANCj4gUmVwb3J0ZWQtYnk6IEplZmYgTW95ZXIgPGptb3llckByZWRoYXQuY29tPg0KPiBS ZXBvcnRlZC1ieTogVmlzaGFsIFZlcm1hIDx2aXNoYWwubC52ZXJtYUBpbnRlbC5jb20+DQo+IFNp Z25lZC1vZmYtYnk6IERhbiBXaWxsaWFtcyA8ZGFuLmoud2lsbGlhbXNAaW50ZWwuY29tPg0KPiAt LS0NCj4gwqBkcml2ZXJzL252ZGltbS9wbWVtLmMgfMKgwqDCoDE0ICsrKysrKysrKysrKysrDQo+ IMKgMSBmaWxlIGNoYW5nZWQsIDE0IGluc2VydGlvbnMoKykNCg0KTG9va3MgZ29vZCwgdGhhbmtz IQ0KDQpSZXZpZXdlZC1ieTogVmlzaGFsIFZlcm1hIDx2aXNoYWwubC52ZXJtYUBpbnRlbC5jb20+ DQoNCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL252ZGltbS9wbWVtLmMgYi9kcml2ZXJzL252 ZGltbS9wbWVtLmMNCj4gaW5kZXggYzZiZWZhYTljNzA4Li5kOWEwZGJjMmQwMjMgMTAwNjQ0DQo+ IC0tLSBhL2RyaXZlcnMvbnZkaW1tL3BtZW0uYw0KPiArKysgYi9kcml2ZXJzL252ZGltbS9wbWVt LmMNCj4gQEAgLTg2LDYgKzg2LDIwIEBAIHN0YXRpYyBpbnQgcG1lbV9kb19idmVjKHN0cnVjdCBw bWVtX2RldmljZSAqcG1lbSwNCj4gc3RydWN0IHBhZ2UgKnBhZ2UsDQo+IMKgCQkJZmx1c2hfZGNh Y2hlX3BhZ2UocGFnZSk7DQo+IMKgCQl9DQo+IMKgCX0gZWxzZSB7DQo+ICsJCS8qDQo+ICsJCcKg KiBOb3RlIHRoYXQgd2Ugd3JpdGUgdGhlIGRhdGEgYm90aCBiZWZvcmUgYW5kIGFmdGVyDQo+ICsJ CcKgKiBjbGVhcmluZyBwb2lzb24uwqDCoFRoZSB3cml0ZSBiZWZvcmUgY2xlYXIgcG9pc29uDQo+ ICsJCcKgKiBoYW5kbGVzIHNpdHVhdGlvbnMgd2hlcmUgdGhlIGxhdGVzdCB3cml0dGVuIGRhdGEN Cj4gaXMNCj4gKwkJwqAqIHByZXNlcnZlZCBhbmQgdGhlIGNsZWFyIHBvaXNvbiBvcGVyYXRpb24g c2ltcGx5DQo+IG1hcmtzDQo+ICsJCcKgKiB0aGUgYWRkcmVzcyByYW5nZSBhcyB2YWxpZCB3aXRo b3V0IGNoYW5naW5nIHRoZQ0KPiBkYXRhLg0KPiArCQnCoCogSW4gdGhpcyBjYXNlIGFwcGxpY2F0 aW9uIHNvZnR3YXJlIGNhbiBhc3N1bWUgdGhhdA0KPiBhbg0KPiArCQnCoCogaW50ZXJydXB0ZWQg d3JpdGUgd2lsbCBlaXRoZXIgcmV0dXJuIHRoZSBuZXcgZ29vZA0KPiArCQnCoCogZGF0YSBvciBh biBlcnJvci4NCj4gKwkJwqAqDQo+ICsJCcKgKiBIb3dldmVyLCBpZiBwbWVtX2NsZWFyX3BvaXNv bigpIGxlYXZlcyB0aGUgZGF0YQ0KPiBpbiBhbg0KPiArCQnCoCogaW5kZXRlcm1pbmF0ZSBzdGF0 ZSB3ZSBuZWVkIHRvIHBlcmZvcm0gdGhlIHdyaXRlDQo+ICsJCcKgKiBhZnRlciBjbGVhciBwb2lz b24uDQo+ICsJCcKgKi8NCj4gwqAJCWZsdXNoX2RjYWNoZV9wYWdlKHBhZ2UpOw0KPiDCoAkJbWVt Y3B5X3RvX3BtZW0ocG1lbV9hZGRyLCBtZW0gKyBvZmYsIGxlbik7DQo+IMKgCQlpZiAodW5saWtl bHkoYmFkX3BtZW0pKSB7DQo+IApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpMaW51eC1udmRpbW0gbWFpbGluZyBsaXN0CkxpbnV4LW52ZGltbUBsaXN0cy4w MS5vcmcKaHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1udmRpbW0K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752921AbcDOQ6X (ORCPT ); Fri, 15 Apr 2016 12:58:23 -0400 Received: from mga02.intel.com ([134.134.136.20]:33360 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751692AbcDOQ6W (ORCPT ); Fri, 15 Apr 2016 12:58:22 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,488,1455004800"; d="scan'208";a="785722545" From: "Verma, Vishal L" To: "Williams, Dan J" , "linux-nvdimm@lists.01.org" CC: "linux-kernel@vger.kernel.org" , "jmoyer@redhat.com" Subject: Re: [PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow Thread-Topic: [PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow Thread-Index: AQHRlsBWSgu8OLn38Ue2zkxeA5d+lJ+Lt94A Date: Fri, 15 Apr 2016 16:58:20 +0000 Message-ID: <1460739500.3012.4.camel@intel.com> References: <146068804768.24085.7722589204633361307.stgit@dwillia2-desk3.jf.intel.com> In-Reply-To: <146068804768.24085.7722589204633361307.stgit@dwillia2-desk3.jf.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.176.69] Content-Type: text/plain; charset="utf-8" Content-ID: <39A453E113C88640B3D1A80D7F3D399C@intel.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u3FGwS3G003770 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 > Reported-by: Vishal Verma > Signed-off-by: Dan Williams > --- >  drivers/nvdimm/pmem.c |   14 ++++++++++++++ >  1 file changed, 14 insertions(+) Looks good, thanks! Reviewed-by: Vishal Verma > > 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)) { >