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@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