From: Halil Pasic <pasic@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: linux-s390@vger.kernel.org, Janosch Frank <frankja@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
linux-kernel@vger.kernel.org, Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
iommu@lists.linux-foundation.org
Subject: [RFC PATCH 3/3] dma-mapping: warn on harmful GFP_* flags
Date: Mon, 23 Sep 2019 14:34:18 +0200 [thread overview]
Message-ID: <20190923123418.22695-4-pasic@linux.ibm.com> (raw)
In-Reply-To: <20190923123418.22695-1-pasic@linux.ibm.com>
The commit message of commit 57bf5a8963f8 ("dma-mapping: clear harmful
GFP_* flags in common code") says that probably warn when we encounter
harmful GFP_* flags which we clean -- because the client code is best
case silly if not buggy. I concur with that.
Let's warn once when we encounter silly GFP_* flags. The guys caring
about the respective client code will hopefully fix these soon.
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
---
I'm not too happy with my warning message. Suggestions welcome!
---
include/linux/dma-mapping.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 5024bc863fa7..299f36ac8668 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -823,6 +823,9 @@ extern gfp_t dma_override_gfp_flags(struct device *dev, gfp_t flags);
static inline gfp_t dma_override_gfp_flags(struct device *dev, gfp_t flags)
{
/* let the implementation decide on the zone to allocate from: */
+ dev_WARN_ONCE(dev,
+ flags & (__GFP_DMA32 | __GFP_DMA | __GFP_HIGHMEM),
+ "fixme: don't dma_alloc with any of: __GFP_DMA32, __GFP_DMA, __GFP_HIGHMEM\n");
return flags & ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
}
#endif
--
2.17.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Cornelia Huck <cohuck@redhat.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org
Subject: [RFC PATCH 3/3] dma-mapping: warn on harmful GFP_* flags
Date: Mon, 23 Sep 2019 14:34:18 +0200 [thread overview]
Message-ID: <20190923123418.22695-4-pasic@linux.ibm.com> (raw)
In-Reply-To: <20190923123418.22695-1-pasic@linux.ibm.com>
The commit message of commit 57bf5a8963f8 ("dma-mapping: clear harmful
GFP_* flags in common code") says that probably warn when we encounter
harmful GFP_* flags which we clean -- because the client code is best
case silly if not buggy. I concur with that.
Let's warn once when we encounter silly GFP_* flags. The guys caring
about the respective client code will hopefully fix these soon.
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
---
I'm not too happy with my warning message. Suggestions welcome!
---
include/linux/dma-mapping.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 5024bc863fa7..299f36ac8668 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -823,6 +823,9 @@ extern gfp_t dma_override_gfp_flags(struct device *dev, gfp_t flags);
static inline gfp_t dma_override_gfp_flags(struct device *dev, gfp_t flags)
{
/* let the implementation decide on the zone to allocate from: */
+ dev_WARN_ONCE(dev,
+ flags & (__GFP_DMA32 | __GFP_DMA | __GFP_HIGHMEM),
+ "fixme: don't dma_alloc with any of: __GFP_DMA32, __GFP_DMA, __GFP_HIGHMEM\n");
return flags & ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
}
#endif
--
2.17.1
next prev parent reply other threads:[~2019-09-23 12:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 12:34 [RFC PATCH 0/3] fix dma_mask for CCW devices Halil Pasic
2019-09-23 12:34 ` Halil Pasic
2019-09-23 12:34 ` [RFC PATCH 1/3] dma-mapping: make overriding GFP_* flags arch customizable Halil Pasic
2019-09-23 12:34 ` Halil Pasic
2019-09-23 15:21 ` Christoph Hellwig
2019-09-23 15:21 ` Christoph Hellwig
2019-09-26 12:37 ` Halil Pasic
2019-09-26 12:37 ` Halil Pasic
2019-09-26 13:04 ` Robin Murphy
2019-09-26 13:04 ` Robin Murphy
2019-09-27 0:33 ` Halil Pasic
2019-09-27 0:33 ` Halil Pasic
2019-09-27 21:21 ` Christoph Hellwig
2019-09-27 21:21 ` Christoph Hellwig
2019-09-23 12:34 ` [RFC PATCH 2/3] s390/virtio: fix virtio-ccw DMA without PV Halil Pasic
2019-09-23 12:34 ` Halil Pasic
2019-09-23 12:34 ` Halil Pasic [this message]
2019-09-23 12:34 ` [RFC PATCH 3/3] dma-mapping: warn on harmful GFP_* flags Halil Pasic
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=20190923123418.22695-4-pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=gerald.schaefer@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hch@lst.de \
--cc=heiko.carstens@de.ibm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
/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.