regression with SG DMA buf allocations and IOMMU in low-mem

[Kai Vehmanen]

Hi,

On Fri, 4 Nov 2022, Takashi Iwai wrote:

> On Fri, 04 Nov 2022 15:56:50 +0100, Kai Vehmanen wrote:
> > Looking at 5.15 code, the fallback looks very different, but 
> > in fallback we still use the DMA mapping API via snd_dma_dev_alloc()
> > so even if we go to fallback path, mapping is still ok.
> > 
> > Any ideas which way this should be fixed? Given the many changes
> > I thought it's better to ask early on the list about this.
> 
> Hrm, that's a tough issue.  Basically if dma_alloc_noncontiguous()
> fails, it's really out of memory -- at least under the situation where
> IOMMU is enabled.  The fallback path was introduced for the case where
> there is no IOMMU and noncontiguous allocation fails from the
> beginning.

follow-up to this problem. It turns out there was additional problem
with dma_alloc_noncontiguous that led to ENOMEM much more frequently
than in the past. This required following:
  - your rework in 5.16 to sound/core/memalloc.c for x86 DMA SG
  - IOMMU/DMAR enabled for the device  
  - CONFIG_DMA_REMAP=n (default 'n' on most/all x86 systems before 5.18)

... with above combination, iommu_dma_ops in drivers/iommu/dma-iommu.c 
were not defined for noncontiguous alloc/free, so the 
dma_alloc_noncontiguous() in the end went back to plain 
dma_common_alloc_pages() (single contiguous alloc), which would fail very 
easily when system was in low-mem condition.

In 5.18, this patch was added

  commit f5ff79fddf0efecca538046b5cc20fb3ded2ec4f
  Author: Christoph Hellwig <hch at lst.de>
  Date:   Sat Feb 26 16:40:21 2022 +0100

      dma-mapping: remove CONFIG_DMA_REMAP

... and this basicly fixes the issue again, even when IOMMU is enabled.

Br, Kai