linux-kernel - Re: [PATCH AUTOSEL 5.17 01/22] ASoC: soc-pcm: use GFP

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: <6e3e881b-787d-30d5-054a-2ef43e3731b1@wanadoo.fr>
Date:   Tue, 26 Apr 2022 21:32:53 +0200
From:   Marion & Christophe JAILLET <christophe.jaillet@...adoo.fr>
To:     Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Cc:     Mark Brown <broonie@...nel.org>, lgirdwood@...il.com,
        perex@...ex.cz, tiwai@...e.com, alsa-devel@...a-project.org
Subject: Re: [PATCH AUTOSEL 5.17 01/22] ASoC: soc-pcm: use GFP_KERNEL when the
 code is sleepable

Hi,

I don't think that this patch needs backporting.

It does not fix anything and could introduce some regression if 
b7898396f4bb is not also already backported.
It could avoid some (unlikely?) allocation failure, but as this case is 
already handled ("if (!dpcm)"), it shouldn't be an issue if it happened.


Just for my understanding, why has it auto-selected for backport?
I thought that a Fixes tag and/or a real reported issue was need for 
this to happen.

CJ



Le 26/04/2022 à 21:01, Sasha Levin a écrit :
> From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
>
> [ Upstream commit fb6d679fee95d272c0a94912c4e534146823ee89 ]
>
> At the kzalloc() call in dpcm_be_connect(), there is no spin lock involved.
> It's merely protected by card->pcm_mutex, instead.  The spinlock is applied
> at the later call with snd_soc_pcm_stream_lock_irq() only for the list
> manipulations.  (See it's *_irq(), not *_irqsave(); that means the context
> being sleepable at that point.)  So, we can use GFP_KERNEL safely there.
>
> This patch revert commit d8a9c6e1f676 ("ASoC: soc-pcm: use GFP_ATOMIC for
> dpcm structure") which is no longer needed since commit b7898396f4bb
> ("ASoC: soc-pcm: Fix and cleanup DPCM locking").
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
> Link: https://lore.kernel.org/r/e740f1930843060e025e3c0f17ec1393cfdafb26.1648757961.git.christophe.jaillet@wanadoo.fr
> Signed-off-by: Mark Brown <broonie@...nel.org>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---
>   sound/soc/soc-pcm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
> index 9a954680d492..11c9853e9e80 100644
> --- a/sound/soc/soc-pcm.c
> +++ b/sound/soc/soc-pcm.c
> @@ -1214,7 +1214,7 @@ static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe,
>   		be_substream->pcm->nonatomic = 1;
>   	}
>   
> -	dpcm = kzalloc(sizeof(struct snd_soc_dpcm), GFP_ATOMIC);
> +	dpcm = kzalloc(sizeof(struct snd_soc_dpcm), GFP_KERNEL);
>   	if (!dpcm)
>   		return -ENOMEM;
>