From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: "Williams, Dan J" Subject: Re: [PATCH 5/5] block: enable dax for raw block devices Date: Thu, 22 Oct 2015 16:05:46 +0000 Message-ID: <1445529945.17208.4.camel@intel.com> References: <20151022064142.12700.11849.stgit@dwillia2-desk3.amr.corp.intel.com> <20151022064211.12700.77105.stgit@dwillia2-desk3.amr.corp.intel.com> <20151022093549.GE14445@quack.suse.cz> In-Reply-To: <20151022093549.GE14445@quack.suse.cz> Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-ID: <0B5FD146F4C0674B9E174AA9A408A4A2@intel.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org To: "jack@suse.cz" Cc: "linux-kernel@vger.kernel.org" , "jmoyer@redhat.com" , "hch@lst.de" , "axboe@fb.com" , "akpm@linux-foundation.org" , "linux-nvdimm@lists.01.org" , "willy@linux.intel.com" , "ross.zwisler@linux.intel.com" , "david@fromorbit.com" List-ID: T24gVGh1LCAyMDE1LTEwLTIyIGF0IDExOjM1ICswMjAwLCBKYW4gS2FyYSB3cm90ZToNCj4gT24g VGh1IDIyLTEwLTE1IDAyOjQyOjExLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+ID4gSWYgYW4gYXBw bGljYXRpb24gd2FudHMgZXhjbHVzaXZlIGFjY2VzcyB0byBhbGwgb2YgdGhlIHBlcnNpc3RlbnQg bWVtb3J5DQo+ID4gcHJvdmlkZWQgYnkgYW4gTlZESU1NIG5hbWVzcGFjZSBpdCBjYW4gdXNlIHRo aXMgcmF3LWJsb2NrLWRheCBmYWNpbGl0eQ0KPiA+IHRvIGZvcmdvIGVzdGFibGlzaGluZyBhIGZp bGVzeXN0ZW0uICBUaGlzIGNhcGFiaWxpdHkgaXMgdGFyZ2V0ZWQNCj4gPiBwcmltYXJpbHkgdG8g aHlwZXJ2aXNvcnMgd2FudGluZyB0byBwcm92aXNpb24gcGVyc2lzdGVudCBtZW1vcnkgZm9yDQo+ ID4gZ3Vlc3RzLg0KPiA+IA0KPiA+IENjOiBKYW4gS2FyYSA8amFja0BzdXNlLmN6Pg0KPiA+IENj OiBKZWZmIE1veWVyIDxqbW95ZXJAcmVkaGF0LmNvbT4NCj4gPiBDYzogQ2hyaXN0b3BoIEhlbGx3 aWcgPGhjaEBsc3QuZGU+DQo+ID4gQ2M6IERhdmUgQ2hpbm5lciA8ZGF2aWRAZnJvbW9yYml0LmNv bT4NCj4gPiBDYzogQW5kcmV3IE1vcnRvbiA8YWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZz4NCj4g PiBDYzogUm9zcyBad2lzbGVyIDxyb3NzLnp3aXNsZXJAbGludXguaW50ZWwuY29tPg0KPiA+IFNp Z25lZC1vZmYtYnk6IERhbiBXaWxsaWFtcyA8ZGFuLmoud2lsbGlhbXNAaW50ZWwuY29tPg0KPiA+ IC0tLQ0KPiA+ICBmcy9ibG9ja19kZXYuYyB8ICAgNTQgKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKystDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCA1MyBp bnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+ID4gDQo+ID4gZGlmZiAtLWdpdCBhL2ZzL2Js b2NrX2Rldi5jIGIvZnMvYmxvY2tfZGV2LmMNCj4gPiBpbmRleCAzMjU1ZGNlYzk2YjQuLmMyN2Nk MWEyMWExMyAxMDA2NDQNCj4gPiAtLS0gYS9mcy9ibG9ja19kZXYuYw0KPiA+ICsrKyBiL2ZzL2Js b2NrX2Rldi5jDQo+ID4gQEAgLTE2ODcsMTMgKzE2ODcsNjUgQEAgc3RhdGljIGNvbnN0IHN0cnVj dCBhZGRyZXNzX3NwYWNlX29wZXJhdGlvbnMgZGVmX2Jsa19hb3BzID0gew0KPiA+ICAJLmlzX2Rp cnR5X3dyaXRlYmFjayA9IGJ1ZmZlcl9jaGVja19kaXJ0eV93cml0ZWJhY2ssDQo+ID4gIH07DQo+ ID4gIA0KPiA+ICsjaWZkZWYgQ09ORklHX0ZTX0RBWA0KPiA+ICsvKg0KPiA+ICsgKiBJbiB0aGUg cmF3IGJsb2NrIGNhc2Ugd2UgZG8gbm90IG5lZWQgdG8gY29udGVuZCB3aXRoIHRydW5jYXRpb24g bm9yDQo+ID4gKyAqIHVud3JpdHRlbiBmaWxlIGV4dGVudHMuICBXaXRob3V0IHRob3NlIGNvbmNl cm5zIHRoZXJlIGlzIG5vIG5lZWQgZm9yDQo+ID4gKyAqIGFkZGl0aW9uYWwgbG9ja2luZyBiZXlv bmQgdGhlIG1tYXBfc2VtIGNvbnRleHQgdGhhdCB0aGVzZSByb3V0aW5lcw0KPiA+ICsgKiBhcmUg YWxyZWFkeSBleGVjdXRpbmcgdW5kZXIuDQo+ID4gKyAqDQo+ID4gKyAqIE5vdGUsIHRoZXJlIGlz IG5vIHByb3RlY3Rpb24gaWYgdGhlIGJsb2NrIGRldmljZSBpcyBkeW5hbWljYWxseQ0KPiA+ICsg KiByZXNpemVkIChwYXJ0aXRpb24gZ3Jvdy9zaHJpbmspIGR1cmluZyBhIGZhdWx0LiBBIHN0YWJs ZSBibG9jayBkZXZpY2UNCj4gPiArICogc2l6ZSBpcyBhbHJlYWR5IG5vdCBlbmZvcmNlZCBpbiB0 aGUgYmxrZGV2X2RpcmVjdF9JTyBwYXRoLg0KPiA+ICsgKg0KPiA+ICsgKiBGb3IgREFYLCBpdCBp cyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIGJsb2NrIGRldmljZSBkcml2ZXIgdG8NCj4gPiAr ICogZW5zdXJlIHRoZSB3aG9sZS1kaXNrIGRldmljZSBzaXplIGlzIHN0YWJsZSB3aGlsZSByZXF1 ZXN0cyBhcmUgaW4NCj4gPiArICogZmxpZ2h0Lg0KPiA+ICsgKg0KPiA+ICsgKiBGaW5hbGx5LCB0 aGVzZSBwYXRocyBkbyBub3Qgc3luY2hyb25pemUgYWdhaW5zdCBmcmVlemluZw0KPiA+ICsgKiAo c2Jfc3RhcnRfcGFnZWZhdWx0KCksIGV0Yy4uLikgc2luY2UgYmRldl9zb3BzIGRvZXMgbm90IHN1 cHBvcnQNCj4gPiArICogZnJlZXppbmcuDQo+IA0KPiBXZWxsLCBmb3IgZGV2aWNlcyBmcmVlemlu ZyBpcyBoYW5kbGVkIGRpcmVjdGx5IGluIHRoZSBibG9jayBsYXllciBjb2RlDQo+IChibGtfc3Rv cF9xdWV1ZSgpKSBzaW5jZSB0aGVyZSdzIG5vIG5lZWQgdG8gcHV0IHNvbWUgbWV0YWRhdGEgc3Ry dWN0dXJlcw0KPiBpbnRvIGEgY29uc2lzdGVudCBzdGF0ZS4gU28gdGhlIGNvbW1lbnQgYWJvdXQg YmRldl9zb3BzIGlzIHNvbWV3aGF0DQo+IHN0cmFuZ2UuDQoNClRoaXMgdGV4dCB3YXMgYWltZWQg YXQgdGhlIHJlcXVlc3QgZnJvbSBSb3NzIHRvIGRvY3VtZW50IHRoZSBkaWZmZXJlbmNlcw0KdnMg dGhlIGdlbmVyaWNfZmlsZV9tbWFwKCkgcGF0aC4gIElzIHRoZSBmb2xsb3dpbmcgaW5jcmVtZW50 YWwgY2hhbmdlDQptb3JlIGNsZWFyPw0KDQpkaWZmIC0tZ2l0IGEvZnMvYmxvY2tfZGV2LmMgYi9m cy9ibG9ja19kZXYuYw0KaW5kZXggODQwYWNkNDM4MGQ0Li40YWU4ZmE1NWJkMWUgMTAwNjQ0DQot LS0gYS9mcy9ibG9ja19kZXYuYw0KKysrIGIvZnMvYmxvY2tfZGV2LmMNCkBAIC0xNzAyLDkgKzE3 MDIsMTUgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBhZGRyZXNzX3NwYWNlX29wZXJhdGlvbnMgZGVm X2Jsa19hb3BzID0gew0KICAqIGVuc3VyZSB0aGUgd2hvbGUtZGlzayBkZXZpY2Ugc2l6ZSBpcyBz dGFibGUgd2hpbGUgcmVxdWVzdHMgYXJlIGluDQogICogZmxpZ2h0Lg0KICAqDQotICogRmluYWxs eSwgdGhlc2UgcGF0aHMgZG8gbm90IHN5bmNocm9uaXplIGFnYWluc3QgZnJlZXppbmcNCi0gKiAo c2Jfc3RhcnRfcGFnZWZhdWx0KCksIGV0Yy4uLikgc2luY2UgYmRldl9zb3BzIGRvZXMgbm90IHN1 cHBvcnQNCi0gKiBmcmVlemluZy4NCisgKiBGaW5hbGx5LCBpbiBjb250cmFzdCB0byB0aGUgZ2Vu ZXJpY19maWxlX21tYXAoKSBwYXRoLCB0aGVyZSBhcmUgbm8NCisgKiBjYWxscyB0byBzYl9zdGFy dF9wYWdlZmF1bHQoKS4gIFRoYXQgaXMgbWVhbnQgdG8gc3luY2hyb25pemUgd3JpdGUNCisgKiBm YXVsdHMgYWdhaW5zdCByZXF1ZXN0cyB0byBmcmVlemUgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaWxl c3lzdGVtDQorICogaG9zdGluZyB2bWEtPnZtX2ZpbGUuICBIb3dldmVyLCBpbiB0aGUgY2FzZSBv ZiBhIGJsb2NrIGRldmljZSBzcGVjaWFsDQorICogZmlsZSwgaXQgaXMgYSAwLXNpemVkIGRldmlj ZSBub2RlIHVzdWFsbHkgaG9zdGVkIG9uIGRldnRtcGZzLCBpLmUuDQorICogbm90aGluZyB0byBk byB3aXRoIHRoZSBzdXBlcl9ibG9jayBmb3IgYmRldl9maWxlX2lub2RlKHZtYS0+dm1fZmlsZSku DQorICogV2UgY291bGQgY2FsbCBnZXRfc3VwZXIoKSBpbiB0aGlzIHBhdGggdG8gcmV0cmlldmUg dGhlIHJpZ2h0DQorICogc3VwZXJfYmxvY2ssIGJ1dCB0aGUgZ2VuZXJpY19maWxlX21tYXAoKSBw YXRoIGRvZXMgbm90IGRvIHRoaXMgZm9yDQorICogdGhlIENPTkZJR19GU19EQVg9biBjYXNlLg0K ICAqLw0KIHN0YXRpYyBpbnQgYmxrZGV2X2RheF9mYXVsdChzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3Qg KnZtYSwgc3RydWN0IHZtX2ZhdWx0ICp2bWYpDQogew0KDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965396AbbJVQGc (ORCPT ); Thu, 22 Oct 2015 12:06:32 -0400 Received: from mga09.intel.com ([134.134.136.24]:38652 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965361AbbJVQGO (ORCPT ); Thu, 22 Oct 2015 12:06:14 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,183,1444719600"; d="scan'208";a="669639102" From: "Williams, Dan J" To: "jack@suse.cz" CC: "linux-kernel@vger.kernel.org" , "jmoyer@redhat.com" , "hch@lst.de" , "axboe@fb.com" , "akpm@linux-foundation.org" , "linux-nvdimm@lists.01.org" , "willy@linux.intel.com" , "ross.zwisler@linux.intel.com" , "david@fromorbit.com" Subject: Re: [PATCH 5/5] block: enable dax for raw block devices Thread-Topic: [PATCH 5/5] block: enable dax for raw block devices Thread-Index: AQHRDJWpFpZwVt7ww02fEDBKc5eLI553tj+AgABs8oA= Date: Thu, 22 Oct 2015 16:05:46 +0000 Message-ID: <1445529945.17208.4.camel@intel.com> References: <20151022064142.12700.11849.stgit@dwillia2-desk3.amr.corp.intel.com> <20151022064211.12700.77105.stgit@dwillia2-desk3.amr.corp.intel.com> <20151022093549.GE14445@quack.suse.cz> In-Reply-To: <20151022093549.GE14445@quack.suse.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" Content-ID: <0B5FD146F4C0674B9E174AA9A408A4A2@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 t9MG6avi003450 On Thu, 2015-10-22 at 11:35 +0200, Jan Kara wrote: > On Thu 22-10-15 02:42:11, Dan Williams wrote: > > If an application wants exclusive access to all of the persistent memory > > provided by an NVDIMM namespace it can use this raw-block-dax facility > > to forgo establishing a filesystem. This capability is targeted > > primarily to hypervisors wanting to provision persistent memory for > > guests. > > > > Cc: Jan Kara > > Cc: Jeff Moyer > > Cc: Christoph Hellwig > > Cc: Dave Chinner > > Cc: Andrew Morton > > Cc: Ross Zwisler > > Signed-off-by: Dan Williams > > --- > > fs/block_dev.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 53 insertions(+), 1 deletion(-) > > > > diff --git a/fs/block_dev.c b/fs/block_dev.c > > index 3255dcec96b4..c27cd1a21a13 100644 > > --- a/fs/block_dev.c > > +++ b/fs/block_dev.c > > @@ -1687,13 +1687,65 @@ static const struct address_space_operations def_blk_aops = { > > .is_dirty_writeback = buffer_check_dirty_writeback, > > }; > > > > +#ifdef CONFIG_FS_DAX > > +/* > > + * In the raw block case we do not need to contend with truncation nor > > + * unwritten file extents. Without those concerns there is no need for > > + * additional locking beyond the mmap_sem context that these routines > > + * are already executing under. > > + * > > + * Note, there is no protection if the block device is dynamically > > + * resized (partition grow/shrink) during a fault. A stable block device > > + * size is already not enforced in the blkdev_direct_IO path. > > + * > > + * For DAX, it is the responsibility of the block device driver to > > + * ensure the whole-disk device size is stable while requests are in > > + * flight. > > + * > > + * Finally, these paths do not synchronize against freezing > > + * (sb_start_pagefault(), etc...) since bdev_sops does not support > > + * freezing. > > Well, for devices freezing is handled directly in the block layer code > (blk_stop_queue()) since there's no need to put some metadata structures > into a consistent state. So the comment about bdev_sops is somewhat > strange. This text was aimed at the request from Ross to document the differences vs the generic_file_mmap() path. Is the following incremental change more clear? diff --git a/fs/block_dev.c b/fs/block_dev.c index 840acd4380d4..4ae8fa55bd1e 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1702,9 +1702,15 @@ static const struct address_space_operations def_blk_aops = { * ensure the whole-disk device size is stable while requests are in * flight. * - * Finally, these paths do not synchronize against freezing - * (sb_start_pagefault(), etc...) since bdev_sops does not support - * freezing. + * Finally, in contrast to the generic_file_mmap() path, there are no + * calls to sb_start_pagefault(). That is meant to synchronize write + * faults against requests to freeze the contents of the filesystem + * hosting vma->vm_file. However, in the case of a block device special + * file, it is a 0-sized device node usually hosted on devtmpfs, i.e. + * nothing to do with the super_block for bdev_file_inode(vma->vm_file). + * We could call get_super() in this path to retrieve the right + * super_block, but the generic_file_mmap() path does not do this for + * the CONFIG_FS_DAX=n case. */ static int blkdev_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I