Re: [PATCH v2 0/2] Add snd_card_disconnect_sync() helper

[Takashi Iwai <tiwai@suse.de>]

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