From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753901AbeC1PMx (ORCPT ); Wed, 28 Mar 2018 11:12:53 -0400 Received: from smtprelay.synopsys.com ([198.182.47.9]:54741 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753512AbeC1PMv (ORCPT ); Wed, 28 Mar 2018 11:12:51 -0400 From: Evgeniy Didin To: "hch@lst.de" , "x86@kernel.org" CC: "linux-kernel@vger.kernel.org" , "sebott@linux.vnet.ibm.com" , "linux-arch@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "Evgeniy.Didin@synopsys.com" , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH] dma-mapping: don't clear GFP_ZERO in dma_alloc_attrs Thread-Topic: [PATCH] dma-mapping: don't clear GFP_ZERO in dma_alloc_attrs Thread-Index: AQHTxpm0Ohq39fhgq0eJ/kMWcZgH36Pln7kA Date: Wed, 28 Mar 2018 15:12:47 +0000 Message-ID: <1522249966.2593.14.camel@synopsys.com> References: <20180328133535.17302-1-hch@lst.de> <20180328133535.17302-2-hch@lst.de> In-Reply-To: <20180328133535.17302-2-hch@lst.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.3.44] Content-Type: text/plain; charset="utf-8" Content-ID: <39D21B2E5947E541869FC01EB34E3DE5@internal.synopsys.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 w2SFCw3c025381 Adding linux-snps and linux-arch mailing lists. > Revert the clearing of __GFP_ZERO in dma_alloc_attrs and move it to > dma_direct_alloc for now.  While most common architectures always zero dma > cohereny allocations (and x86 did so since day one) this is not documented > and at least arc and s390 do not zero without the explicit __GFP_ZERO > argument. This patch fixed Ethernet issues on ARC HSDK. https://www.spinics.net/lists/kernel/msg2762054.html Tested-by: Evgeniy Didin > Fixes: 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") > Reported-by: Evgeniy Didin > Reported-by: Sebastian Ott > Signed-off-by: Christoph Hellwig > --- >  include/linux/dma-mapping.h | 8 ++------ >  lib/dma-direct.c            | 3 +++ >  2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index eb9eab4ecd6d..12fedcba9a9a 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -518,12 +518,8 @@ static inline void *dma_alloc_attrs(struct device *dev, size_t size, >   if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr)) >   return cpu_addr; >   > - /* > -  * Let the implementation decide on the zone to allocate from, and > -  * decide on the way of zeroing the memory given that the memory > -  * returned should always be zeroed. > -  */ > - flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM | __GFP_ZERO); > + /* let the implementation decide on the zone to allocate from: */ > + flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM); > >   if (!arch_dma_alloc_attrs(&dev, &flag)) >   return NULL; > diff --git a/lib/dma-direct.c b/lib/dma-direct.c > index 1277d293d4da..c0bba30fef0a 100644 > --- a/lib/dma-direct.c > +++ b/lib/dma-direct.c > @@ -59,6 +59,9 @@ void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, >   struct page *page = NULL; >   void *ret; >   > + /* we always manually zero the memory once we are done: */ > + gfp &= ~__GFP_ZERO; > + >   /* GFP_DMA32 and GFP_DMA are no ops without the corresponding zones: */ >   if (dev->coherent_dma_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS)) >   gfp |= GFP_DMA; From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgeniy Didin Subject: Re: [PATCH] dma-mapping: don't clear GFP_ZERO in dma_alloc_attrs Date: Wed, 28 Mar 2018 15:12:47 +0000 Message-ID: <1522249966.2593.14.camel@synopsys.com> References: <20180328133535.17302-1-hch@lst.de> <20180328133535.17302-2-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20180328133535.17302-2-hch-jcswGhMUV9g@public.gmane.org> Content-Language: en-US Content-ID: <39D21B2E5947E541869FC01EB34E3DE5-z7JfP6tgrtVBCHUSTMH8dZqQE7yCjDx5@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "hch-jcswGhMUV9g@public.gmane.org" , "x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" Cc: "linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Evgeniy.Didin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: linux-arch.vger.kernel.org QWRkaW5nIGxpbnV4LXNucHMgYW5kIGxpbnV4LWFyY2ggbWFpbGluZyBsaXN0cy4NCg0KPiBSZXZl cnQgdGhlIGNsZWFyaW5nIG9mIF9fR0ZQX1pFUk8gaW4gZG1hX2FsbG9jX2F0dHJzIGFuZCBtb3Zl IGl0IHRvDQo+IGRtYV9kaXJlY3RfYWxsb2MgZm9yIG5vdy7CoMKgV2hpbGUgbW9zdCBjb21tb24g YXJjaGl0ZWN0dXJlcyBhbHdheXMgemVybyBkbWENCj4gY29oZXJlbnkgYWxsb2NhdGlvbnMgKGFu ZCB4ODYgZGlkIHNvIHNpbmNlIGRheSBvbmUpIHRoaXMgaXMgbm90IGRvY3VtZW50ZWQNCj4gYW5k IGF0IGxlYXN0IGFyYyBhbmQgczM5MCBkbyBub3QgemVybyB3aXRob3V0IHRoZSBleHBsaWNpdCBf X0dGUF9aRVJPDQo+IGFyZ3VtZW50Lg0KVGhpcyBwYXRjaCBmaXhlZCBFdGhlcm5ldCBpc3N1ZXMg b24gQVJDIEhTREsuDQpodHRwczovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9rZXJuZWwvbXNnMjc2 MjA1NC5odG1sDQoNClRlc3RlZC1ieTogRXZnZW5peSBEaWRpbiA8RXZnZW5peS5EaWRpbkBzeW5v cHN5cy5jb20+DQo+IEZpeGVzOiA1N2JmNWE4OTYzZjggKCJkbWEtbWFwcGluZzogY2xlYXIgaGFy bWZ1bCBHRlBfKiBmbGFncyBpbiBjb21tb24gY29kZSIpDQo+IFJlcG9ydGVkLWJ5OiBFdmdlbml5 IERpZGluIDxFdmdlbml5LkRpZGluQHN5bm9wc3lzLmNvbT4NCj4gUmVwb3J0ZWQtYnk6IFNlYmFz dGlhbiBPdHQgPHNlYm90dEBsaW51eC52bmV0LmlibS5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IENo cmlzdG9waCBIZWxsd2lnIDxoY2hAbHN0LmRlPg0KPiAtLS0NCj4gwqBpbmNsdWRlL2xpbnV4L2Rt YS1tYXBwaW5nLmggfCA4ICsrLS0tLS0tDQo+IMKgbGliL2RtYS1kaXJlY3QuY8KgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoHwgMyArKysNCj4gwqAyIGZpbGVzIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygr KSwgNiBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9pbmNsdWRlL2xpbnV4L2RtYS1t YXBwaW5nLmggYi9pbmNsdWRlL2xpbnV4L2RtYS1tYXBwaW5nLmgNCj4gaW5kZXggZWI5ZWFiNGVj ZDZkLi4xMmZlZGNiYTlhOWEgMTAwNjQ0DQo+IC0tLSBhL2luY2x1ZGUvbGludXgvZG1hLW1hcHBp bmcuaA0KPiArKysgYi9pbmNsdWRlL2xpbnV4L2RtYS1tYXBwaW5nLmgNCj4gQEAgLTUxOCwxMiAr NTE4LDggQEAgc3RhdGljIGlubGluZSB2b2lkICpkbWFfYWxsb2NfYXR0cnMoc3RydWN0IGRldmlj ZSAqZGV2LCBzaXplX3Qgc2l6ZSwNCj4gwqAJaWYgKGRtYV9hbGxvY19mcm9tX2Rldl9jb2hlcmVu dChkZXYsIHNpemUsIGRtYV9oYW5kbGUsICZjcHVfYWRkcikpDQo+IMKgCQlyZXR1cm4gY3B1X2Fk ZHI7DQo+IMKgDQo+IC0JLyoNCj4gLQnCoCogTGV0IHRoZSBpbXBsZW1lbnRhdGlvbiBkZWNpZGUg b24gdGhlIHpvbmUgdG8gYWxsb2NhdGUgZnJvbSwgYW5kDQo+IC0JwqAqIGRlY2lkZSBvbiB0aGUg d2F5IG9mIHplcm9pbmcgdGhlIG1lbW9yeSBnaXZlbiB0aGF0IHRoZSBtZW1vcnkNCj4gLQnCoCog cmV0dXJuZWQgc2hvdWxkIGFsd2F5cyBiZSB6ZXJvZWQuDQo+IC0JwqAqLw0KPiAtCWZsYWcgJj0g fihfX0dGUF9ETUEgfCBfX0dGUF9ETUEzMiB8IF9fR0ZQX0hJR0hNRU0gfCBfX0dGUF9aRVJPKTsN Cj4gKwkvKiBsZXQgdGhlIGltcGxlbWVudGF0aW9uIGRlY2lkZSBvbiB0aGUgem9uZSB0byBhbGxv Y2F0ZSBmcm9tOiAqLw0KPiArCWZsYWcgJj0gfihfX0dGUF9ETUEgfCBfX0dGUF9ETUEzMiB8IF9f R0ZQX0hJR0hNRU0pOw0KPiANCj4gwqAJaWYgKCFhcmNoX2RtYV9hbGxvY19hdHRycygmZGV2LCAm ZmxhZykpDQo+IMKgCQlyZXR1cm4gTlVMTDsNCj4gZGlmZiAtLWdpdCBhL2xpYi9kbWEtZGlyZWN0 LmMgYi9saWIvZG1hLWRpcmVjdC5jDQo+IGluZGV4IDEyNzdkMjkzZDRkYS4uYzBiYmEzMGZlZjBh IDEwMDY0NA0KPiAtLS0gYS9saWIvZG1hLWRpcmVjdC5jDQo+ICsrKyBiL2xpYi9kbWEtZGlyZWN0 LmMNCj4gQEAgLTU5LDYgKzU5LDkgQEAgdm9pZCAqZG1hX2RpcmVjdF9hbGxvYyhzdHJ1Y3QgZGV2 aWNlICpkZXYsIHNpemVfdCBzaXplLCBkbWFfYWRkcl90ICpkbWFfaGFuZGxlLA0KPiDCoAlzdHJ1 Y3QgcGFnZSAqcGFnZSA9IE5VTEw7DQo+IMKgCXZvaWQgKnJldDsNCj4gwqANCj4gKwkvKiB3ZSBh bHdheXMgbWFudWFsbHkgemVybyB0aGUgbWVtb3J5IG9uY2Ugd2UgYXJlIGRvbmU6ICovDQo+ICsJ Z2ZwICY9IH5fX0dGUF9aRVJPOw0KPiArDQo+IMKgCS8qIEdGUF9ETUEzMiBhbmQgR0ZQX0RNQSBh cmUgbm8gb3BzIHdpdGhvdXQgdGhlIGNvcnJlc3BvbmRpbmcgem9uZXM6ICovDQo+IMKgCWlmIChk ZXYtPmNvaGVyZW50X2RtYV9tYXNrIDw9IERNQV9CSVRfTUFTSyhBUkNIX1pPTkVfRE1BX0JJVFMp KQ0KPiDCoAkJZ2ZwIHw9IEdGUF9ETUE7Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmlvbW11IG1haWxpbmcgbGlzdAppb21tdUBsaXN0cy5saW51eC1mb3Vu ZGF0aW9uLm9yZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pb21tdQ== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgeniy.Didin@synopsys.com (Evgeniy Didin) Date: Wed, 28 Mar 2018 15:12:47 +0000 Subject: [PATCH] dma-mapping: don't clear GFP_ZERO in dma_alloc_attrs In-Reply-To: <20180328133535.17302-2-hch@lst.de> References: <20180328133535.17302-1-hch@lst.de> <20180328133535.17302-2-hch@lst.de> List-ID: Message-ID: <1522249966.2593.14.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org Adding linux-snps and linux-arch mailing lists. > Revert the clearing of __GFP_ZERO in dma_alloc_attrs and move it to > dma_direct_alloc for now.??While most common architectures always zero dma > cohereny allocations (and x86 did so since day one) this is not documented > and at least arc and s390 do not zero without the explicit __GFP_ZERO > argument. This patch fixed Ethernet issues on ARC HSDK. https://www.spinics.net/lists/kernel/msg2762054.html Tested-by: Evgeniy Didin > Fixes: 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") > Reported-by: Evgeniy Didin > Reported-by: Sebastian Ott > Signed-off-by: Christoph Hellwig > --- > ?include/linux/dma-mapping.h | 8 ++------ > ?lib/dma-direct.c????????????| 3 +++ > ?2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index eb9eab4ecd6d..12fedcba9a9a 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -518,12 +518,8 @@ static inline void *dma_alloc_attrs(struct device *dev, size_t size, > ? if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr)) > ? return cpu_addr; > ? > - /* > - ?* Let the implementation decide on the zone to allocate from, and > - ?* decide on the way of zeroing the memory given that the memory > - ?* returned should always be zeroed. > - ?*/ > - flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM | __GFP_ZERO); > + /* let the implementation decide on the zone to allocate from: */ > + flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM); > > ? if (!arch_dma_alloc_attrs(&dev, &flag)) > ? return NULL; > diff --git a/lib/dma-direct.c b/lib/dma-direct.c > index 1277d293d4da..c0bba30fef0a 100644 > --- a/lib/dma-direct.c > +++ b/lib/dma-direct.c > @@ -59,6 +59,9 @@ void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, > ? struct page *page = NULL; > ? void *ret; > ? > + /* we always manually zero the memory once we are done: */ > + gfp &= ~__GFP_ZERO; > + > ? /* GFP_DMA32 and GFP_DMA are no ops without the corresponding zones: */ > ? if (dev->coherent_dma_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS)) > ? gfp |= GFP_DMA;