[PATCH] ASoC: soc-pcm: fix fe and be race when accessing substream->runtime
Cezary Rojewski
cezary.rojewski at intel.com
Tue Sep 27 09:50:05 CEST 2022
On 2022-09-26 6:35 PM, Eugeniu Rosca wrote:
> From: xiao jin <jin.xiao at intel.com>
>
> After start of fe and be, fe might go to close without triggering
> STOP, and substream->runtime is freed. However, be is still at
> START state and its substream->runtime still points to the
> freed runtime.
>
> Later on, FE is opened/started again, and triggers STOP.
> snd_pcm_do_stop => dpcm_fe_dai_trigger
> => dpcm_fe_dai_do_trigger
> => dpcm_be_dai_trigger
> => dpcm_do_trigger
> => soc_pcm_trigger
> => skl_platform_pcm_trigger
> skl_platform_pcm_trigger accesses the freed old runtime data and
> kernel panic.
>
> The patch fixes it by assigning be_substream->runtime in
> dpcm_be_dai_startup when be's state is START.
>
> Signed-off-by: xiao jin <jin.xiao at intel.com>
> Signed-off-by: Zhang Yanmin <yanmin.zhang at intel.com>
> Signed-off-by: Eugeniu Rosca <erosca at de.adit-jv.com>
Hello,
The change seems to be driven by the skylake-driver problem. With all
due respect, why not ping owners of the driver first? There are some
crucial CCs missing.
I'd like to know more about the scenario you guys reproduced the problem
in. Configuration details and kernel base would be good to know too.
Since our CI did not detect problem of such sort, if the problem
actually exists, we would like to append a test or two to cover it later on.
Regards,
Czarek
More information about the Alsa-devel
mailing list