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@wanadoo.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@wanadoo.fr Link: https://lore.kernel.org/r/e740f1930843060e025e3c0f17ec1393cfdafb26.164875796... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.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;