[RFC PATCH v2 0/5] ASoC: soc-pcm: fix trigger race conditions with shared BE
Takashi Iwai
tiwai at suse.de
Fri Oct 8 08:13:39 CEST 2021
On Thu, 07 Oct 2021 23:27:50 +0200,
Pierre-Louis Bossart wrote:
>
>
>
> >> I think the only solution is to follow the example of the PCM case,
> >> where the type of lock depends on the FE types, with the assumption that
> >> there are no mixed atomic/non-atomic FE configurations.
> >
> > Yes, and I guess we can simply replace those all card->dpcm_lock with
> > FE's stream lock. It'll solve the atomicity problem, too, and the FE
> > stream lock can be applied outside the loop of dpcm_be_disconnect()
> > gracefully.
> >
> > And, this should solve the race with dpcm_be_dai_trigger() as well,
> > because it's called from dpcm_fe_dai_trigger() that is called already
> > inside the FE's stream lock held by PCM core. A PoC is something like
> > below. (I replaced the superfluous *_irqsave with *_irq there)
>
> No I don't think so. The code starts from an FE and loops for all the
> BEs connected to that FE, but we want to serialize at the BE level! we
> really need a dpcm lock at the card level, not the FE/stream level.
The FE lock prevents the race between dpcm_be_dai_trigger() and
dpcm_be_disconnect(), i.e. the problem Gyeongtaek showed.
The race among concurrent dpcm_be_dai_trigger() calls itself can be
addressed by BE stream locks as suggested earlier.
Takashi
More information about the Alsa-devel
mailing list