On Mon, 16 Oct 2017 04:26:42 +0200, Kuninori Morimoto wrote:
Hi Takashi
I could confirm this by printing who's stop was called by local quick hack.
Maybe timing reason, if kernel has Oops for some reasons, then, both BE/FE snd_pcm_stop() are called. If no Oops, BE snd_pcm_stop() only called.
Any pending delayed work (like rtd->delayed_work)? This is flushed at soc_cleanup_card_resources(), but it's called at card removal, thus it's too late for the hot-removal of the component.
Current my dirver used delayed_work, but we can control it by snd_soc_runtime_ignore_pmdown_time(); I think my driver now doesn't use delayed_work.
But there is still issue. I don't know detail, but it seems snd_pcm_dev_disconnect() and snd_pcm_relase() are called it the same time, both are calling snd_pcm_stop().
Then, snd_pcm_relase() side will calls snd_pcm_detach_substream() and snd_pcm_dev_disconnect() side will die.
This must be also specific to DPCM. Something is really wrong there.
Basically snd_pcm_dev_disconnect() and snd_pcm_release() can't race since both are protected via pcm->open_mutex. snd_pcm_stop() calls are protected even more with substream lock.
Mark's suggestion (= hiding BE) can solve this ?
Some of the issues might be addressed, yes, but I'm skeptical whether it covers all. The BE needs proper locking and refcounting that is coupled with the FE, I suppose.
Takashi