fix GFP_COMP use in noncoherent dma allocators
Hi all,
this series fixe the regression where dma-iommu stopped clearing GFP_COMP from noncoherent dma allocations by never requesting those in the sound code and rejecting them in the core DMA API code.
Diffstat: kernel/dma/mapping.c | 4 ++++ sound/core/memalloc.c | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-)
While not quite as bogus as for the dma-coherent allocations that were fixed earlier, GFP_COMP for these allocations has no benefits for the dma-direct case, and can't be supported at all by dma dma-iommu backend which splits up allocations into smaller orders. Due to an oversight in ffcb75458460 that flag stopped being cleared for all dma allocations, but only got rejected for coherent ones.
Start fixing this by not requesting __GFP_COMP in the sound code, which is the only place that did this.
Fixes: ffcb75458460 ("dma-mapping: reject __GFP_COMP in dma_alloc_attrs") Reported-by: Mikhail Gavrilov mikhail.v.gavrilov@gmail.com Reported-by: Kai Vehmanen kai.vehmanen@linux.intel.com Signed-off-by: Christoph Hellwig hch@lst.de --- sound/core/memalloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c index 3cf5a87d69eaf3..81025f50a54229 100644 --- a/sound/core/memalloc.c +++ b/sound/core/memalloc.c @@ -542,7 +542,7 @@ static void *snd_dma_noncontig_alloc(struct snd_dma_buffer *dmab, size_t size) void *p;
sgt = dma_alloc_noncontiguous(dmab->dev.dev, size, dmab->dev.dir, - DEFAULT_GFP | __GFP_COMP, 0); + DEFAULT_GFP, 0); #ifdef CONFIG_SND_DMA_SGBUF if (!sgt && !get_dma_ops(dmab->dev.dev)) { if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC_SG) @@ -820,7 +820,7 @@ static void *snd_dma_noncoherent_alloc(struct snd_dma_buffer *dmab, size_t size) void *p;
p = dma_alloc_noncoherent(dmab->dev.dev, size, &dmab->addr, - dmab->dev.dir, DEFAULT_GFP | __GFP_COMP); + dmab->dev.dir, DEFAULT_GFP); if (p) dmab->dev.need_sync = dma_need_sync(dmab->dev.dev, dmab->addr); return p;
While not quite as bogus as for the dma-coherent allocations that were fixed earlier, GFP_COMP for these allocations has no benefits for the dma-direct case, and can't be supported at all by dma dma-iommu backend which splits up allocations into smaller orders. Due to an oversight in ffcb75458460 that flag stopped being cleared for all dma allocations, but only got rejected for coherent ones, so fix up these callers to not allow __GFP_COMP as well after the sound code has been fixed to not ask for it.
Fixes: ffcb75458460 ("dma-mapping: reject __GFP_COMP in dma_alloc_attrs") Reported-by: Mikhail Gavrilov mikhail.v.gavrilov@gmail.com Reported-by: Kai Vehmanen kai.vehmanen@linux.intel.com Signed-off-by: Christoph Hellwig hch@lst.de --- kernel/dma/mapping.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index c026a5a5e0466e..68106e3791f6c3 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -560,6 +560,8 @@ static struct page *__dma_alloc_pages(struct device *dev, size_t size, return NULL; if (WARN_ON_ONCE(gfp & (__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM))) return NULL; + if (WARN_ON_ONCE(gfp & __GFP_COMP)) + return NULL;
size = PAGE_ALIGN(size); if (dma_alloc_direct(dev, ops)) @@ -645,6 +647,8 @@ struct sg_table *dma_alloc_noncontiguous(struct device *dev, size_t size,
if (WARN_ON_ONCE(attrs & ~DMA_ATTR_ALLOC_SINGLE_PAGES)) return NULL; + if (WARN_ON_ONCE(gfp & __GFP_COMP)) + return NULL;
if (ops && ops->alloc_noncontiguous) sgt = ops->alloc_noncontiguous(dev, size, dir, gfp, attrs);
Hey,
On Tue, 20 Dec 2022, Christoph Hellwig wrote:
While not quite as bogus as for the dma-coherent allocations that were fixed earlier, GFP_COMP for these allocations has no benefits for the dma-direct case, and can't be supported at all by dma dma-iommu
tested the series and this fixes the issue: Tested-by: Kai Vehmanen kai.vehmanen@linux.intel.com
Minor nit, typo "noncohernt allocaions" in subject of this second patch.
Br, Kai
On Tue, Dec 20, 2022 at 7:58 PM Kai Vehmanen kai.vehmanen@linux.intel.com wrote:
Hey,
On Tue, 20 Dec 2022, Christoph Hellwig wrote:
While not quite as bogus as for the dma-coherent allocations that were fixed earlier, GFP_COMP for these allocations has no benefits for the dma-direct case, and can't be supported at all by dma dma-iommu
tested the series and this fixes the issue: Tested-by: Kai Vehmanen kai.vehmanen@linux.intel.com
Minor nit, typo "noncohernt allocaions" in subject of this second patch.
Br, Kai
I also confirm that after applying this patch series issue was gone.
Tested-by: Mikhail Gavrilov mikhail.v.gavrilov@gmail.com
Thanks.
On Tue, 20 Dec 2022 09:20:07 +0100, Christoph Hellwig wrote:
Hi all,
this series fixe the regression where dma-iommu stopped clearing GFP_COMP from noncoherent dma allocations by never requesting those in the sound code and rejecting them in the core DMA API code.
Diffstat: kernel/dma/mapping.c | 4 ++++ sound/core/memalloc.c | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-)
Thank you Christoph for taking care of this mess, and apologies for my delayed reaction, as I've been (still) on vacation since the last week.
FWIW, feel free to take my ack for the sound part:
Acked-by: Takashi Iwai tiwai@suse.de
Takashi
participants (4)
-
Christoph Hellwig -
Kai Vehmanen -
Mikhail Gavrilov -
Takashi Iwai