linux-kernel - Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu case

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG-rBigFG-U-sKY77CvzghGzs+1Xm3YXzBF6N4ti0+h6UdAb8Q@mail.gmail.com>
Date: Thu, 15 Feb 2024 11:07:38 -0500
From: Sven van Ashbrook <svenva@...omium.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Hillf Danton <hdanton@...a.com>, Karthikeyan Ramasubramanian <kramasub@...omium.org>, 
	LKML <linux-kernel@...r.kernel.org>, Brian Geffon <bgeffon@...gle.com>, 
	linux-sound@...r.kernel.org
Subject: Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu case

Hi Takashi,

On Thu, Feb 15, 2024 at 3:40 AM Takashi Iwai <tiwai@...e.de> wrote:
>
> Yes, the main problem is the indefinite hang from
> dma_alloc_noncontiguous().

We have a publicly-visible test [1] which readily triggers the
indefinite hang on non-iommu Intel SoCs such as JasperLake.
As noted in the commit message, iommu SoCs are not currently
affected.

> So, is the behavior more or less same even if you pass
> __GFP_RETRY_MAYFAIL to dma_alloc_noncontiguous()?  Or is this flag
> already implicitly set somewhere in the middle?  It shouldn't hang
> indefinitely, but the other impact to the system like OOM-killer
> kickoff may be seen.

My incomplete understanding:

Alsa specifies __GFP_RETRY_MAYFAIL because it wants to prevent triggering
the OOM killer. This was __GFP_NORETRY in the not-too-distant past [2],
but that failed too quickly, which resulted in permanent loss of audio due
to failed firmware dma sg allocations.

In the iommu case, dma_alloc_noncontiguous() implements a backoff [3] loop
which ORs in __GFP_NORETRY except for minimum order allocations. We observe
experimentally that __GFP_RETRY_MAYFAIL does not get "stuck" on minimum order
allocations. So the iommu case is not affected.

In the non-iommu case however, dma_alloc_noncontiguous() actually becomes a
contiguous allocator, with no backoff loop. The commit introducing it [4]
states "This API is only properly implemented for dma-iommu and will simply
return a contigious chunk as a fallback." In this case we observe the indefinite
hang.

The alsa fallback allocator is also not affected by the problem, as it does
not specify __GFP_RETRY_MAYFAIL. Except in the XENPV case.

Sven

[1] https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/autotest/files/client/site_tests/power_LowMemorySuspend/control

[2] a61c7d8 ("ALSA: memalloc: use __GFP_RETRY_MAYFAIL for DMA mem allocs")

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/dma-iommu.c?h=v6.8-rc4#n903

[4] 7d5b573 ("dma-mapping: add a dma_alloc_noncontiguous API")