fix up nowarn confusion in the dma mapping layer
Hi all,
this series sorts out how we deal with the nowarn flags in the dma mapping code. We still support __GFP_NOWARN for the legacy APIs that don't support passing the dma specific flags, but we generally want every implementation to actually check DMA_ATTR_NO_WARN instead.
PATCH 1/2 dma-mapping: translate __GFP_NOFAIL to DMA_ATTR_NO_WARN
This allows all dma_map_ops instances to entirely rely on DMA_ATTR_NO_WARN going forward.
--- include/linux/dma-mapping.h | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
include/linux/dma-mapping.h +10 -4
@@ -557,9 +557,11 @@ static inline void dma_free_attrs(struct device *dev, size_t size, }static inline void *dma_alloc_coherent (struct device *dev,size_t size, -dma_addr_t *dma_handle,gfp_t flag) +dma_addr_t *dma_handle,gfp_t gfp) { -return dma_alloc_attrs (dev, size, dma_handle, flag,0 ); + +return dma_alloc_attrs (dev, size, dma_handle, gfp, + (gfp & __GFP_NOWARN) ?DMA_ATTR_NO_WARN :0 ); } static inline void dma_free_coherent(struct device *dev, size_t size,
@@ -793,8 +795,12 @@ static inline void dmam_release_declared_memory(struct device *dev)static inline void *dma_alloc_wc (struct device *dev,size_t size,dma_addr_t *dma_addr,gfp_t gfp) { -return dma_alloc_attrs (dev, size, dma_addr, gfp, -DMA_ATTR_WRITE_COMBINE ); +unsigned long attrs =DMA_ATTR_NO_WARN ; + +if (gfp & __GFP_NOWARN) + attrs |=DMA_ATTR_NO_WARN ; + +return dma_alloc_attrs (dev, size, dma_addr, gfp, attrs); }#ifndef dma_alloc_writecombine#define dma_alloc_writecombine dma_alloc_wc
Signature · 1 line
2.19.0
PATCH 2/2 dma-direct: respect DMA_ATTR_NO_WARN
In reply to Christoph HellwigRespect the DMA_ATTR_NO_WARN flags for allocations in dma-direct.
--- kernel/dma/direct.c | 3 +++ 1 file changed, 3 insertions(+)
kernel/dma/direct.c +3 -0
@@ -107,6 +107,9 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,u64 phys_mask;void *ret; +if (attrs &DMA_ATTR_NO_WARN ) + gfp |= __GFP_NOWARN; +/* we always manually zero the memory once we are done: */ gfp &= ~__GFP_ZERO; gfp |= __dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
Signature · 1 line
2.19.0
Any comments on these rather trivial patches?
Quoted 10 lines · Christoph Hellwig
Hi all,
this series sorts out how we deal with the nowarn flags in the dma mapping code. We still support
__GFP_NOWARNfor the legacy APIs that don't support passing the dma specific flags, but we generally want every implementation to actually checkDMA_ATTR_NO_WARNinstead.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---
Quoted 1 line · Christoph Hellwig
Any comments on these rather trivial patches?
Nope ;)
For both,
Quoted 13 lines · Christoph Hellwig
Quoted 10 lines
Hi all,
this series sorts out how we deal with the nowarn flags in the dma mapping code. We still support
__GFP_NOWARNfor the legacy APIs that don't support passing the dma specific flags, but we generally want every implementation to actually checkDMA_ATTR_NO_WARNinstead.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu---end quoted text---