fix GFP_COMP use in noncoherent dma allocators

fix GFP_COMP use in noncoherent dma allocators

[Christoph Hellwig]

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(-)

[PATCH 1/2] ALSA: memalloc: don't use GFP_COMP for non-coherent dma allocations

[Christoph Hellwig]

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;
-- 
2.35.1

[PATCH 2/2] dma-mapping: reject GFP_COMP for noncohernt allocaions

[Christoph Hellwig]

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);
-- 
2.35.1

Re: [PATCH 2/2] dma-mapping: reject GFP_COMP for noncohernt allocaions

[Kai Vehmanen]

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

Re: [PATCH 2/2] dma-mapping: reject GFP_COMP for noncohernt allocaions

[Mikhail Gavrilov]

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.

-- 
Best Regards,
Mike Gavrilov.

Re: [PATCH 2/2] dma-mapping: reject GFP_COMP for noncohernt allocaions

[Christoph Hellwig]

On Tue, Dec 20, 2022 at 04:57:25PM +0200, Kai Vehmanen wrote:
> Minor nit, typo "noncohernt allocaions" in subject of this second patch.

Thanks,

I've fixed this and queued up the series.

Re: fix GFP_COMP use in noncoherent dma allocators

[Takashi Iwai]

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