From: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
To: "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
"hch@lst.de" <hch@lst.de>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
"jesper.nilsson@axis.com" <jesper.nilsson@axis.com>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.
Date: Tue, 27 Mar 2018 17:12:54 +0000 [thread overview]
Message-ID: <1522170774.2593.9.camel@synopsys.com> (raw)
Hello,
After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") we noticed problems with Ethernet controller on one of our platforms (namely ARC HSDK).
I
n particular we see that removal of __GFP_ZERO flag in function dma_alloc_attrs() was the culprit because in our implementation of arc_dma_alloc() we only allocate zeroed pages if
that flag is explicitly set by the caller. Now with unconditional removal of that flag in dma_alloc_attrs() we allocate non-zeroed pages and that seem to cause problems.
From
mentioned commit message I may conclude that architectural code is supposed to always allocate zeroed pages but I cannot find any requirement of that in kernel's documentation.
Coul
d you please point me to that requirement if that exists at all, then we'll implement a fix in our arch code like that:
--------------------->8---------------------
return NULL;
--------------------->8---------------------
Best regards,
Evgeniy Didin
diff --git
a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 1dcc404b5aec..c92e518413aa 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -30,7 +30,7 @@ static void *arc_dma_alloc(struct
device *dev, size_t size,
void *kvaddr;
int need_coh = 1, need_kvaddr = 0;
- page = alloc_pages(gfp, order);
+ page = alloc_pages(gfp | __GFP_ZERO, order);
if (!page)
WARNING: multiple messages have this Message-ID (diff)
From: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
To: "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
"hch@lst.de" <hch@lst.de>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
"jesper.nilsson@axis.com" <jesper.nilsson@axis.com>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.
Date: Tue, 27 Mar 2018 17:12:54 +0000 [thread overview]
Message-ID: <1522170774.2593.9.camel@synopsys.com> (raw)
Hello,
After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") we noticed problems with Ethernet controller on one of our platforms (namely ARC HSDK).
I
n particular we see that removal of __GFP_ZERO flag in function dma_alloc_attrs() was the culprit because in our implementation of arc_dma_alloc() we only allocate zeroed pages if
that flag is explicitly set by the caller. Now with unconditional removal of that flag in dma_alloc_attrs() we allocate non-zeroed pages and that seem to cause problems.
From
mentioned commit message I may conclude that architectural code is supposed to always allocate zeroed pages but I cannot find any requirement of that in kernel's documentation.
Coul
d you please point me to that requirement if that exists at all, then we'll implement a fix in our arch code like that:
--------------------->8---------------------
diff --git
a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 1dcc404b5aec..c92e518413aa 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -30,7 +30,7 @@ static void *arc_dma_alloc(struct
device *dev, size_t size,
void *kvaddr;
int need_coh = 1, need_kvaddr = 0;
- page = alloc_pages(gfp, order);
+ page = alloc_pages(gfp | __GFP_ZERO, order);
if (!page)
return NULL;
--------------------->8---------------------
Best regards,
Evgeniy Didin
WARNING: multiple messages have this Message-ID (diff)
From: Evgeniy.Didin@synopsys.com (Evgeniy Didin)
To: linux-snps-arc@lists.infradead.org
Subject: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.
Date: Tue, 27 Mar 2018 17:12:54 +0000 [thread overview]
Message-ID: <1522170774.2593.9.camel@synopsys.com> (raw)
Hello,
After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") we noticed problems with Ethernet controller on one of our platforms (namely ARC HSDK).
I
n particular we see that removal of __GFP_ZERO flag in function dma_alloc_attrs() was the culprit because in our implementation of arc_dma_alloc() we only allocate zeroed pages if
that flag is explicitly set by the caller. Now with unconditional removal of that flag in dma_alloc_attrs() we allocate non-zeroed pages and that seem to cause problems.
From
mentioned commit message I may conclude that architectural code is supposed to always allocate zeroed pages but I cannot find any requirement of that in kernel's documentation.
Coul
d you please point me to that requirement if that exists at all, then we'll implement a fix in our arch code like that:
--------------------->8---------------------
diff --git
a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 1dcc404b5aec..c92e518413aa 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -30,7 +30,7 @@ static void *arc_dma_alloc(struct
device *dev, size_t size,
void *kvaddr;
int need_coh = 1, need_kvaddr = 0;
- page = alloc_pages(gfp, order);
+ page = alloc_pages(gfp | __GFP_ZERO, order);
if (!page)
return NULL;
--------------------->8---------------------
Best regards,
Evgeniy Didin
next reply other threads:[~2018-03-27 17:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-27 17:12 Evgeniy Didin [this message]
2018-03-27 17:12 ` dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board Evgeniy Didin
2018-03-27 17:12 ` Evgeniy Didin
-- strict thread matches above, loose matches on Subject: below --
2018-03-27 18:11 Andy Shevchenko
2018-03-27 18:11 ` Andy Shevchenko
2018-03-27 18:11 ` Andy Shevchenko
2018-03-27 18:11 ` Andy Shevchenko
2018-03-27 18:24 Vineet Gupta
2018-03-27 18:24 ` Vineet Gupta
2018-03-27 18:24 ` Vineet Gupta
2018-03-27 18:24 ` Vineet Gupta
2018-03-27 18:24 ` Vineet Gupta
2018-03-27 21:19 Alexey Brodkin
2018-03-27 21:19 ` Alexey Brodkin
2018-03-27 21:19 ` Alexey Brodkin
2018-03-27 21:19 ` Alexey Brodkin
2018-03-28 7:53 Christoph Hellwig
2018-03-28 7:53 ` hch
2018-03-28 7:53 ` hch
2018-03-28 7:53 ` hch-jcswGhMUV9g
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1522170774.2593.9.camel@synopsys.com \
--to=evgeniy.didin@synopsys.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=Eugeniy.Paltsev@synopsys.com \
--cc=dmaengine@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jesper.nilsson@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.