From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kani, Toshimitsu" Subject: Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices Date: Tue, 21 Jun 2016 16:35:56 +0000 Message-ID: <1466526342.3504.270.camel@hpe.com> References: <1465856497-19698-1-git-send-email-toshi.kani@hpe.com> <20160613225756.GA18417@redhat.com> <20160620180043.GA21261@redhat.com> <1466446861.3504.243.camel@hpe.com> <20160620194026.GA21657@redhat.com> <20160620195217.GB21657@redhat.com> <1466452883.3504.244.camel@hpe.com> <1466457467.3504.249.camel@hpe.com> <20160620222236.GA22461@redhat.com> <20160621134147.GA26392@redhat.com> <1466523280.3504.262.camel@hpe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-US Content-ID: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: "dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" Cc: "axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org" , "sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "axboe-b10kYP2dOMg@public.gmane.org" , "linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org" , "agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" List-Id: dm-devel.ids T24gVHVlLCAyMDE2LTA2LTIxIGF0IDA5OjI1IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+ IE9uIFR1ZSwgSnVuIDIxLCAyMDE2IGF0IDg6NDQgQU0sIEthbmksIFRvc2hpbWl0c3UgPHRvc2hp LmthbmlAaHBlLmNvbT4NCj4gd3JvdGU6DQo+ID4gDQo+ID4gT24gVHVlLCAyMDE2LTA2LTIxIGF0 IDA5OjQxIC0wNDAwLCBNaWtlIFNuaXR6ZXIgd3JvdGU6DQo+ID4gPiANCj4gPiA+IE9uIE1vbiwg SnVuIDIwIDIwMTYgYXTCoMKgNjoyMnBtIC0wNDAwLA0KPiA+ID4gTWlrZSBTbml0emVyIDxzbml0 emVyQHJlZGhhdC5jb20+IHdyb3RlOg0KPiA+ID4gPiANCj4gPiA+ID4gT24gTW9uLCBKdW4gMjAg MjAxNiBhdMKgwqA1OjI4cG0gLTA0MDAsDQo+ID4gPiA+IEthbmksIFRvc2hpbWl0c3UgPHRvc2hp LmthbmlAaHBlLmNvbT4gd3JvdGU6DQo+ID4gwqA6DQo+ID4gPiA+IExvb2tzIGdvb2QsIEkgZm9s ZGVkIGl0IGluIGFuZCB0ZXN0ZWQgaXQgdG8gd29yay7CoMKgUHVzaGVkIHRvIG15ICd3aXAnDQo+ ID4gPiA+IGJyYW5jaC4NCj4gPiA+ID4gDQo+ID4gPiA+IE5vIGxvbmdlciBzZWVpbmcgYW55IGNv cnJ1cHRpb24gaW4gbXkgdGVzdCB0aGF0IHdhcyB1c2luZyBwYXJ0aXRpb25zDQo+ID4gPiA+IHRv IHNwYW4gcG1lbSBkZXZpY2VzIHdpdGggYSBkbS1saW5lYXIgZGV2aWNlLg0KPiA+ID4gPiANCj4g PiA+ID4gSmVucywgYW55IGNoYW5jZSB5b3UnZCBiZSBvcGVuIHRvIHBpY2tpbmcgdXAgdGhlIGZp cnN0IDIgcGF0Y2hlcyBpbg0KPiA+ID4gPiB0aGlzIHNlcmllcz/CoMKgT3Igd291bGQgeW91IGxp a2UgdG8gc2VlIHRoZW0gZm9sZGVkIG9yIHNvbWV0aGluZw0KPiA+ID4gPiBkaWZmZXJlbnQ/DQo+ ID4gPg0KPiA+ID4gSSdtIG5vdyB3b25kZXJpbmcgaWYgd2UnZCBiZSBiZXR0ZXIgb2ZmIHNldHRp bmcgYSBuZXcgUVVFVUVfRkxBR19EQVgNCj4gPiA+IHJhdGhlciB0aGFuIGVzdGFibGlzaCBHRU5I RF9GTF9EQVggb24gdGhlIGdlbmhkPw0KPiA+ID4gDQo+ID4gPiBJdCdkIGJlIHF1aXRlIGEgYml0 IGVhc2llciB0byBhbGxvdyB1cHBlciBsYXllcnMgKGUuZy4gWEZTIGFuZCBleHQ0KSB0bw0KPiA+ ID4gY2hlY2sgZm9yIGEgcXVldWUgZmxhZy4NCj4gPg0KPiA+IEkgdGhpbmsgR0VOSERfRkxfREFY IGlzIG1vcmUgYXBwcm9wcmlhdGUgc2luY2UgREFYIGRvZXMgbm90IHVzZSBhIHJlcXVlc3QNCj4g PiBxdWV1ZSwgZXhjZXB0IGZvciBwcm90ZWN0aW5nIHRoZSB1bmRlcmxpbmluZyBkZXZpY2UgYmVp bmcgZGlzYWJsZWQgd2hpbGUNCj4gPiBkaXJlY3RfYWNjZXNzKCkgaXMgY2FsbGVkIChiMmUwZDE2 MjVlMTkpLg0KPiA+IA0KPiA+IEFib3V0IHByb3RlY3RpbmcgZGlyZWN0X2FjY2VzcywgdGhpcyBw YXRjaCBhc3N1bWVzIHRoYXQgdGhlIHVuZGVybGluaW5nDQo+ID4gZGV2aWNlIGNhbm5vdCBiZSBk aXNhYmxlZCB1bnRpbCBkdHIoKSBpcyBjYWxsZWQuwqDCoElzIHRoaXMgY29ycmVjdD/CoMKgSWYN Cj4gPiBub3QsIEkgd2lsbCBuZWVkIHRvIGNhbGwgZGF4X21hcF9hdG9taWMoKS4NCj4NCj4gS2Vy bmVsIGludGVybmFsIHVzYWdlcyBvZiBkYXggc2hvdWxkIGJlIHVzaW5nIGRheF9tYXBfYXRvbWlj KCkgdG8NCj4gc2FmZWx5IHJlc29sdmUgZGV2aWNlIHJlbW92YWwgcmFjZXMuDQoNCldpbGwgZG8u IMKgSW4gc3VjaCBjYXNlLCBzaGFsbCBJIG1vdmXCoGRheF9bdW5dbWFwX2F0b21pYygpIHRvIGJs b2NrX2Rldi5jIGFuZA0KcmVuYW1lIHRoZW0gdG8gYmRldl9kYXhfW3VuXW1hcF9hdG9taWMoKT8N Cg0KVGhhbmtzLA0KLVRvc2hpCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCkxpbnV4LW52ZGltbSBtYWlsaW5nIGxpc3QKTGludXgtbnZkaW1tQGxpc3RzLjAx Lm9yZwpodHRwczovL2xpc3RzLjAxLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW52ZGltbQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752482AbcFUQwV (ORCPT ); Tue, 21 Jun 2016 12:52:21 -0400 Received: from mail-by2on0129.outbound.protection.outlook.com ([207.46.100.129]:60576 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751804AbcFUQwS (ORCPT ); Tue, 21 Jun 2016 12:52:18 -0400 X-Greylist: delayed 73468 seconds by postgrey-1.27 at vger.kernel.org; Tue, 21 Jun 2016 12:52:18 EDT From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" CC: "linux-kernel@vger.kernel.org" , "sandeen@redhat.com" , "linux-nvdimm@ml01.01.org" , "agk@redhat.com" , "linux-raid@vger.kernel.org" , "snitzer@redhat.com" , "viro@zeniv.linux.org.uk" , "axboe@kernel.dk" , "axboe@fb.com" , "ross.zwisler@linux.intel.com" , "dm-devel@redhat.com" Subject: Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices Thread-Topic: [PATCH 0/6] Support DAX for device-mapper dm-linear devices Thread-Index: AQHRxcNvFc0gDtWw/UKSuO/qIYbBN5/oAoaAgAqtRoCAAAWsgIAAFjAAgAADUICAAAKLgIAAFViAgAASHACAAQDRgIAAH4oAgAAOIQCAAAAhAA== Date: Tue, 21 Jun 2016 16:35:56 +0000 Message-ID: <1466526342.3504.270.camel@hpe.com> References: <1465856497-19698-1-git-send-email-toshi.kani@hpe.com> <20160613225756.GA18417@redhat.com> <20160620180043.GA21261@redhat.com> <1466446861.3504.243.camel@hpe.com> <20160620194026.GA21657@redhat.com> <20160620195217.GB21657@redhat.com> <1466452883.3504.244.camel@hpe.com> <1466457467.3504.249.camel@hpe.com> <20160620222236.GA22461@redhat.com> <20160621134147.GA26392@redhat.com> <1466523280.3504.262.camel@hpe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=toshi.kani@hpe.com; x-originating-ip: [15.219.163.9] x-ms-office365-filtering-correlation-id: 782fc4c3-2577-4ec1-bbe0-08d399f21e74 x-microsoft-exchange-diagnostics: 1;CS1PR84MB0007;6:Llo67o/rgobNK4AkfT0/k/4K97n/RO9qN+5p+U/2GJzVkT+djJHX8JzhzC0kJfnYRiQXBMB4t6aME3sU13Z9aa+hjPa7UsvF3/46Zw8WqzoAym51i+ROTD56AwFONyU0Jro6ytQKl9l7AqsiGsUhs3K9ONzatJ8ENfWfno+y+v6Jz+4e7s/SAfltiyvvenzkVS0g+JwiffP+dg1uFlu1XpLItrdmKeR2qQVFmig4Kgq1FVUmOghQ4r+FwuqFjE1RddbLDCQHcqsBDleTUDOzZS4wh1CcgdLiNp03Rz+FZVI=;5:KBD8U5F/JpsPEuiehidgqraWw7FpCIXjC95LmXOj3qjKtlBm16+MJckgF6DBBsQEkyy9Q08KsTQUxXxzRU0+JnZ5JesymYNEIqQ1d8OEXF/OyfkeddOC55kowTSKXUhMNI3/fjundDNMPitW7czPmw==;24:Ajwz2Rl12fV2wktVnge5iT5THfsoM4rQD2Uj29s3OOgbB00u1SktviZuh7SRGxceUhxRDWNRDD5LtfJLu0I2NqjzHgWY0vZcSm6Nd+ru20c=;7:k9s9TyXktKZgvqA445Xo102w1BSOUYQ+dJ2HQABGboayrzGbm6OBoemYKr6401ipc4ZkGcGjcqLIq+5H4ViAJCN/OX1uJWjtMtnWC7sqJGpgiTrk36c5AaPMrmQPcibBXYZ2sQlWRno//Rh/ueOqw6x/fD+zhGEJu/hIIfxF/R38DLNI1chkVU33Iy9aYBuxFBRBihfiVgoOiiQE1+Hv0WGKpqFbqEgVrwkURpnaXjLKd5NX6H7lzF4n8b/o7rts x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0007; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001);SRVR:CS1PR84MB0007;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0007; x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(24454002)(377424004)(199003)(189002)(377454003)(87936001)(11100500001)(8676002)(5640700001)(101416001)(2501003)(103116003)(575784001)(86362001)(93886004)(189998001)(36756003)(122556002)(81156014)(3280700002)(50986999)(76176999)(106116001)(54356999)(2351001)(66066001)(7736002)(105586002)(7846002)(68736007)(106356001)(92566002)(8936002)(99286002)(19580405001)(19580395003)(6116002)(33646002)(5002640100001)(77096005)(102836003)(3846002)(110136002)(2906002)(10400500002)(97736004)(3660700001)(2950100001)(81166006)(4326007)(2900100001)(586003);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR84MB0007;H:CS1PR84MB0005.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2016 16:35:56.0893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0007 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 u5LGqRwB002973 On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: > On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu > wrote: > > > > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at  6:22pm -0400, > > > Mike Snitzer wrote: > > > > > > > > On Mon, Jun 20 2016 at  5:28pm -0400, > > > > Kani, Toshimitsu wrote: > >  : > > > > Looks good, I folded it in and tested it to work.  Pushed to my 'wip' > > > > branch. > > > > > > > > No longer seeing any corruption in my test that was using partitions > > > > to span pmem devices with a dm-linear device. > > > > > > > > Jens, any chance you'd be open to picking up the first 2 patches in > > > > this series?  Or would you like to see them folded or something > > > > different? > > > > > > I'm now wondering if we'd be better off setting a new QUEUE_FLAG_DAX > > > rather than establish GENHD_FL_DAX on the genhd? > > > > > > It'd be quite a bit easier to allow upper layers (e.g. XFS and ext4) to > > > check for a queue flag. > > > > I think GENHD_FL_DAX is more appropriate since DAX does not use a request > > queue, except for protecting the underlining device being disabled while > > direct_access() is called (b2e0d1625e19). > > > > About protecting direct_access, this patch assumes that the underlining > > device cannot be disabled until dtr() is called.  Is this correct?  If > > not, I will need to call dax_map_atomic(). > > Kernel internal usages of dax should be using dax_map_atomic() to > safely resolve device removal races. Will do.  In such case, shall I move dax_[un]map_atomic() to block_dev.c and rename them to bdev_dax_[un]map_atomic()? Thanks, -Toshi