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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.22.394.2402161246520.14041@eliteleevi.tm.intel.com>
Date: Fri, 16 Feb 2024 14:19:54 +0200 (EET)
From: Kai Vehmanen <kai.vehmanen@...ux.intel.com>
To: Takashi Iwai <tiwai@...e.de>
cc: Hillf Danton <hdanton@...a.com>, Sven van Ashbrook <svenva@...omium.org>, 
    Karthikeyan Ramasubramanian <kramasub@...omium.org>, 
    LKML <linux-kernel@...r.kernel.org>, Brian Geffon <bgeffon@...gle.com>, 
    linux-sound@...r.kernel.org, Kai Vehmanen <kai.vehmanen@...ux.intel.com>, 
    "Arava, Jairaj" <jairaj.arava@...el.com>
Subject: Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu
 case

Hi,

On Fri, 16 Feb 2024, Takashi Iwai wrote:

> On Fri, 16 Feb 2024 09:35:32 +0100, Takashi Iwai wrote:
> > The fact that we have to drop __GFP_RETRY_MAYFAIL indicates that the
> > handling there doesn't suffice -- at least for the audio operation.
> 
> Reconsidering on this again, I wonder keeping __GFP_RETRY_MAYFAIL
> makes sense.  We did have __GFP_NORETRY for avoiding OOM-killer.
> But it's been over ages, and the memory allocation core became smart
> enough.
> 
> The side-effect of __GFP_RETRY_MAYFAIL is that the page reclaim and
> compaction happens even for high-order allocations, and that must be

for the original problem that led to "ALSA: memalloc: use 
__GFP_RETRY_MAYFAIL for DMA mem allocs", reclaim for low-order case
would be enough. I.e. the case was:

> OTOH, a slight concern with the drop of __GFP_RETRY_MAYFAIL is whether
> allowing OOM-killer for low order allocations is acceptable or not.
> 
> There are two patterns of calling allocators:
[..]
> 3. SNDRV_DMA_TYPE_NONCONTIG for large size:
>    this is called often, once per stream open, since the driver
>    doesn't keep the buffer.

So with SOF we have additional case where we do an allocation for the DSP 
firmware (snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_SG, ...)) and this is 
called at system resume. With s/__GPF_RETRY_MAYFAIL/__GFP_NORETRY/, these 
allocations failed (on a iommu enabled Chromebook) at system resume in a 
case where system was not really running out of memory (reclaim was 
possible). A failed allocation means there's no audio in the system after 
resume, so we want to try harder.

But yeah, I think the proposed handling for (3) category would work. If 
needed, we can further specialize the DSP firmware case with some hint 
to snd_dma_alloc_pages().

Br, Kai