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 12:52:44 -0600 Message-ID: <1460573564.24985.60.camel@hpe.com> References: <1460493572-31667-1-git-send-email-toshi.kani@hpe.com> <20160413030156.GN2781@linux.intel.com> <1460560116.24985.55.camel@hpe.com> <20160413182249.GB3120@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: <20160413182249.GB3120@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Wed, 2016-04-13 at 14:22 -0400, Matthew Wilcox wrote: > On Wed, Apr 13, 2016 at 09:08:36AM -0600, Toshi Kani wrote: > >=20 > > >=20 > > > Could you do something like: > > >=20 > > > =C2=A0#ifdef CONFIG_FS_DAX > > > =C2=A0struct page *read_dax_sector(struct block_device *bdev, sec= tor_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, unsigne= d long > > > flags); > > > =C2=A0#else > > > =C2=A0static inline struct page *read_dax_sector(struct block_dev= ice > > > *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 e= ach > > > filesystem. > > > > I thought about it, but I do not think we can use an inline functio= n to > > an entry point. > > That's not an inline function.=C2=A0=C2=A0It's just NULL.=C2=A0=C2=A0= So after the > preprocessor is done with it, it just looks like: >=20 > .get_unmapped_area =3D NULL, >=20 > and it won't be called by get_unmapped_area(). Oh, I see. Good idea. I will do that. Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t3428.houston.hp.com (g4t3428.houston.hp.com [15.201.208.56]) (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 BBE221A1E7E for ; Wed, 13 Apr 2016 12:01:16 -0700 (PDT) Message-ID: <1460573564.24985.60.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 12:52:44 -0600 In-Reply-To: <20160413182249.GB3120@linux.intel.com> References: <1460493572-31667-1-git-send-email-toshi.kani@hpe.com> <20160413030156.GN2781@linux.intel.com> <1460560116.24985.55.camel@hpe.com> <20160413182249.GB3120@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: T24gV2VkLCAyMDE2LTA0LTEzIGF0IDE0OjIyIC0wNDAwLCBNYXR0aGV3IFdpbGNveCB3cm90ZToK PiBPbiBXZWQsIEFwciAxMywgMjAxNiBhdCAwOTowODozNkFNIC0wNjAwLCBUb3NoaSBLYW5pIHdy b3RlOgo+ID4gCj4gPiA+IAo+ID4gPiBDb3VsZCB5b3UgZG8gc29tZXRoaW5nIGxpa2U6Cj4gPiA+ IAo+ID4gPiDCoCNpZmRlZiBDT05GSUdfRlNfREFYCj4gPiA+IMKgc3RydWN0IHBhZ2UgKnJlYWRf ZGF4X3NlY3RvcihzdHJ1Y3QgYmxvY2tfZGV2aWNlICpiZGV2LCBzZWN0b3JfdCBuKTsKPiA+ID4g K3Vuc2lnbmVkIGxvbmcgZGF4X2dldF91bm1hcHBlZF9hcmVhKHN0cnVjdCBmaWxlICpmaWxwLCB1 bnNpZ25lZCBsb25nCj4gPiA+IGFkZHIsCj4gPiA+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqB1bnNpZ25lZCBsb25nIGxlbiwgdW5zaWduZWQgbG9uZyBwZ29mZiwgdW5zaWduZWQgbG9u Zwo+ID4gPiBmbGFncyk7Cj4gPiA+IMKgI2Vsc2UKPiA+ID4gwqBzdGF0aWMgaW5saW5lIHN0cnVj dCBwYWdlICpyZWFkX2RheF9zZWN0b3Ioc3RydWN0IGJsb2NrX2RldmljZQo+ID4gPiAqYmRldiwK PiA+ID4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHNlY3Rvcl90IG4pCj4gPiA+ IMKgewo+ID4gPiDCoMKgwqDCoMKgwqDCoMKgwqByZXR1cm4gRVJSX1BUUigtRU5YSU8pOwo+ID4g PiDCoH0KPiA+ID4gKyNkZWZpbmUgZGF4X2dldF91bm1hcHBlZF9hcmVhCU5VTEwKPiA+ID4gwqAj ZW5kaWYKPiA+ID4gCj4gPiA+IGluIHBhdGNoIDEvNS7CoMKgVGhlbiB0aGVyZSdzIG5vIG5lZWQg Zm9yIHRoZSBpZmRlZnMgaW4gZWFjaAo+ID4gPiBmaWxlc3lzdGVtLgo+ID4KPiA+IEkgdGhvdWdo dCBhYm91dCBpdCwgYnV0IEkgZG8gbm90IHRoaW5rIHdlIGNhbiB1c2UgYW4gaW5saW5lIGZ1bmN0 aW9uIHRvCj4gPiBhbiBlbnRyeSBwb2ludC4KPgo+IFRoYXQncyBub3QgYW4gaW5saW5lIGZ1bmN0 aW9uLsKgwqBJdCdzIGp1c3QgTlVMTC7CoMKgU28gYWZ0ZXIgdGhlCj4gcHJlcHJvY2Vzc29yIGlz IGRvbmUgd2l0aCBpdCwgaXQganVzdCBsb29rcyBsaWtlOgo+IAo+IAkuZ2V0X3VubWFwcGVkX2Fy ZWEgPSBOVUxMLAo+IAo+IGFuZCBpdCB3b24ndCBiZSBjYWxsZWQgYnkgZ2V0X3VubWFwcGVkX2Fy ZWEoKS4KCk9oLCBJIHNlZS4gR29vZCBpZGVhLiBJIHdpbGwgZG8gdGhhdC4KClRoYW5rcywKLVRv c2hpCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4 LW52ZGltbSBtYWlsaW5nIGxpc3QKTGludXgtbnZkaW1tQGxpc3RzLjAxLm9yZwpodHRwczovL2xp c3RzLjAxLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW52ZGltbQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932303AbcDMTBS (ORCPT ); Wed, 13 Apr 2016 15:01:18 -0400 Received: from g4t3428.houston.hp.com ([15.201.208.56]:10390 "EHLO g4t3428.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932289AbcDMTBR (ORCPT ); Wed, 13 Apr 2016 15:01:17 -0400 X-Greylist: delayed 14260 seconds by postgrey-1.27 at vger.kernel.org; Wed, 13 Apr 2016 15:01:17 EDT Message-ID: <1460573564.24985.60.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 12:52:44 -0600 In-Reply-To: <20160413182249.GB3120@linux.intel.com> References: <1460493572-31667-1-git-send-email-toshi.kani@hpe.com> <20160413030156.GN2781@linux.intel.com> <1460560116.24985.55.camel@hpe.com> <20160413182249.GB3120@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 Wed, 2016-04-13 at 14:22 -0400, Matthew Wilcox wrote: > On Wed, Apr 13, 2016 at 09:08:36AM -0600, Toshi Kani wrote: > > > > > > > > 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. > > That's not an inline function.  It's just NULL.  So after the > preprocessor is done with it, it just looks like: > > .get_unmapped_area = NULL, > > and it won't be called by get_unmapped_area(). Oh, I see. Good idea. I will do that. Thanks, -Toshi