From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toshi Kani Subject: Re: [PATCH v2 2/5] ext4: call dax_get_unmapped_area() for DAX pmd mappings Date: Wed, 13 Apr 2016 09:08:36 -0600 Message-ID: <1460560116.24985.55.camel@hpe.com> References: <1460493572-31667-1-git-send-email-toshi.kani@hpe.com> <20160413030156.GN2781@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: akpm@linux-foundation.org, dan.j.williams@intel.com, linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Theodore Ts'o , Andreas Dilger , Jan Kara , Ross Zwisler , linux-ext4@vger.kernel.org To: Matthew Wilcox Return-path: In-Reply-To: <20160413030156.GN2781@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Tue, 2016-04-12 at 23:01 -0400, Matthew Wilcox wrote: > On Tue, Apr 12, 2016 at 02:39:29PM -0600, Toshi Kani wrote: > >=20 > > To support DAX pmd mappings with unmodified applications, > > filesystems need to align an mmap address by the pmd size. > >=20 > > @@ -708,6 +708,9 @@ const struct file_operations ext4_file_operatio= ns =3D > > { > > =C2=A0 .open =3D ext4_file_open, > > =C2=A0 .release =3D ext4_release_file, > > =C2=A0 .fsync =3D ext4_sync_file, > > +#ifdef CONFIG_FS_DAX > > + .get_unmapped_area =3D dax_get_unmapped_area, > > +#endif > > =C2=A0 .splice_read =3D generic_file_splice_read, > > =C2=A0 .splice_write =3D iter_file_splice_write, > > =C2=A0 .fallocate =3D ext4_fallocate, > > Could you do something like: >=20 > =C2=A0#ifdef CONFIG_FS_DAX > =C2=A0struct page *read_dax_sector(struct block_device *bdev, sector_= t n); > +unsigned long dax_get_unmapped_area(struct file *filp, unsigned long > addr, > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0unsigned long len, unsigned long pgoff, unsigned l= ong > flags); > =C2=A0#else > =C2=A0static inline struct page *read_dax_sector(struct block_device = *bdev, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0sector_t n) > =C2=A0{ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return ERR_PTR(= -ENXIO); > =C2=A0} > +#define dax_get_unmapped_area NULL > =C2=A0#endif >=20 > in patch 1/5.=C2=A0=C2=A0Then there's no need for the ifdefs in each = filesystem. I thought about it, but I do not think we can use an inline function to= an entry point. Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id DE2F41A21CA for ; Wed, 13 Apr 2016 08:17:07 -0700 (PDT) Message-ID: <1460560116.24985.55.camel@hpe.com> Subject: Re: [PATCH v2 2/5] ext4: call dax_get_unmapped_area() for DAX pmd mappings From: Toshi Kani Date: Wed, 13 Apr 2016 09:08:36 -0600 In-Reply-To: <20160413030156.GN2781@linux.intel.com> References: <1460493572-31667-1-git-send-email-toshi.kani@hpe.com> <20160413030156.GN2781@linux.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: Matthew Wilcox Cc: Theodore Ts'o , linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org, Andreas Dilger , linux-fsdevel@vger.kernel.org, Jan Kara , akpm@linux-foundation.org, linux-ext4@vger.kernel.org List-ID: T24gVHVlLCAyMDE2LTA0LTEyIGF0IDIzOjAxIC0wNDAwLCBNYXR0aGV3IFdpbGNveCB3cm90ZToK PiBPbiBUdWUsIEFwciAxMiwgMjAxNiBhdCAwMjozOToyOVBNIC0wNjAwLCBUb3NoaSBLYW5pIHdy b3RlOgo+ID4gCj4gPiBUbyBzdXBwb3J0IERBWCBwbWQgbWFwcGluZ3Mgd2l0aCB1bm1vZGlmaWVk IGFwcGxpY2F0aW9ucywKPiA+IGZpbGVzeXN0ZW1zIG5lZWQgdG8gYWxpZ24gYW4gbW1hcCBhZGRy ZXNzIGJ5IHRoZSBwbWQgc2l6ZS4KPiA+IAo+ID4gQEAgLTcwOCw2ICs3MDgsOSBAQCBjb25zdCBz dHJ1Y3QgZmlsZV9vcGVyYXRpb25zIGV4dDRfZmlsZV9vcGVyYXRpb25zID0KPiA+IHsKPiA+IMKg CS5vcGVuCQk9IGV4dDRfZmlsZV9vcGVuLAo+ID4gwqAJLnJlbGVhc2UJPSBleHQ0X3JlbGVhc2Vf ZmlsZSwKPiA+IMKgCS5mc3luYwkJPSBleHQ0X3N5bmNfZmlsZSwKPiA+ICsjaWZkZWYgQ09ORklH X0ZTX0RBWAo+ID4gKwkuZ2V0X3VubWFwcGVkX2FyZWEgPSBkYXhfZ2V0X3VubWFwcGVkX2FyZWEs Cj4gPiArI2VuZGlmCj4gPiDCoAkuc3BsaWNlX3JlYWQJPSBnZW5lcmljX2ZpbGVfc3BsaWNlX3Jl YWQsCj4gPiDCoAkuc3BsaWNlX3dyaXRlCT0gaXRlcl9maWxlX3NwbGljZV93cml0ZSwKPiA+IMKg CS5mYWxsb2NhdGUJPSBleHQ0X2ZhbGxvY2F0ZSwKPgo+IENvdWxkIHlvdSBkbyBzb21ldGhpbmcg bGlrZToKPiAKPiDCoCNpZmRlZiBDT05GSUdfRlNfREFYCj4gwqBzdHJ1Y3QgcGFnZSAqcmVhZF9k YXhfc2VjdG9yKHN0cnVjdCBibG9ja19kZXZpY2UgKmJkZXYsIHNlY3Rvcl90IG4pOwo+ICt1bnNp Z25lZCBsb25nIGRheF9nZXRfdW5tYXBwZWRfYXJlYShzdHJ1Y3QgZmlsZSAqZmlscCwgdW5zaWdu ZWQgbG9uZwo+IGFkZHIsCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHVuc2lnbmVk IGxvbmcgbGVuLCB1bnNpZ25lZCBsb25nIHBnb2ZmLCB1bnNpZ25lZCBsb25nCj4gZmxhZ3MpOwo+ IMKgI2Vsc2UKPiDCoHN0YXRpYyBpbmxpbmUgc3RydWN0IHBhZ2UgKnJlYWRfZGF4X3NlY3Rvcihz dHJ1Y3QgYmxvY2tfZGV2aWNlICpiZGV2LAo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqBzZWN0b3JfdCBuKQo+IMKgewo+IMKgwqDCoMKgwqDCoMKgwqDCoHJldHVybiBFUlJfUFRS KC1FTlhJTyk7Cj4gwqB9Cj4gKyNkZWZpbmUgZGF4X2dldF91bm1hcHBlZF9hcmVhCU5VTEwKPiDC oCNlbmRpZgo+IAo+IGluIHBhdGNoIDEvNS7CoMKgVGhlbiB0aGVyZSdzIG5vIG5lZWQgZm9yIHRo ZSBpZmRlZnMgaW4gZWFjaCBmaWxlc3lzdGVtLgoKSSB0aG91Z2h0IGFib3V0IGl0LCBidXQgSSBk byBub3QgdGhpbmsgd2UgY2FuIHVzZSBhbiBpbmxpbmUgZnVuY3Rpb24gdG8gYW4KZW50cnkgcG9p bnQuCgpUaGFua3MsCi1Ub3NoaQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f 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 S1759060AbcDMPRN (ORCPT ); Wed, 13 Apr 2016 11:17:13 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:36268 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751031AbcDMPRK (ORCPT ); Wed, 13 Apr 2016 11:17:10 -0400 Message-ID: <1460560116.24985.55.camel@hpe.com> Subject: Re: [PATCH v2 2/5] ext4: call dax_get_unmapped_area() for DAX pmd mappings From: Toshi Kani To: Matthew Wilcox Cc: akpm@linux-foundation.org, dan.j.williams@intel.com, linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, "Theodore Ts'o" , Andreas Dilger , Jan Kara , Ross Zwisler , linux-ext4@vger.kernel.org Date: Wed, 13 Apr 2016 09:08:36 -0600 In-Reply-To: <20160413030156.GN2781@linux.intel.com> References: <1460493572-31667-1-git-send-email-toshi.kani@hpe.com> <20160413030156.GN2781@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-04-12 at 23:01 -0400, Matthew Wilcox wrote: > On Tue, Apr 12, 2016 at 02:39:29PM -0600, Toshi Kani wrote: > > > > To support DAX pmd mappings with unmodified applications, > > filesystems need to align an mmap address by the pmd size. > > > > @@ -708,6 +708,9 @@ const struct file_operations ext4_file_operations = > > { > >   .open = ext4_file_open, > >   .release = ext4_release_file, > >   .fsync = ext4_sync_file, > > +#ifdef CONFIG_FS_DAX > > + .get_unmapped_area = dax_get_unmapped_area, > > +#endif > >   .splice_read = generic_file_splice_read, > >   .splice_write = iter_file_splice_write, > >   .fallocate = ext4_fallocate, > > Could you do something like: > >  #ifdef CONFIG_FS_DAX >  struct page *read_dax_sector(struct block_device *bdev, sector_t n); > +unsigned long dax_get_unmapped_area(struct file *filp, unsigned long > addr, > +               unsigned long len, unsigned long pgoff, unsigned long > flags); >  #else >  static inline struct page *read_dax_sector(struct block_device *bdev, >                  sector_t n) >  { >          return ERR_PTR(-ENXIO); >  } > +#define dax_get_unmapped_area NULL >  #endif > > in patch 1/5.  Then there's no need for the ifdefs in each filesystem. I thought about it, but I do not think we can use an inline function to an entry point. Thanks, -Toshi