[alsa-devel] [question about DPCM] dpcm_be_disconnect race condition

[Mark Brown]

On Thu, Aug 28, 2014 at 10:07:14AM +0800, Qiao Zhou wrote:
> On 08/28/2014 02:52 AM, Mark Brown wrote:
> >On Wed, Aug 27, 2014 at 04:15:00PM +0800, Qiao Zhou wrote:

> >Well, it should do that in general if it wants to make sure that the
> >audio actually gets played but the kernel should protect against this.
> >We should be holding a lock whenever we update the lists.

> Thanks a lot for your suggestion! Firstly we'll ask user space app to apply
> this rule currently to avoid such issue.
> Currently it holds card->mutex in mutex_lock_nested whenever the list is
> updated. Here list_for_each_entry in snd_pcm_stop may run in interrupt
> context(the bottom half of tasklet), so it can not use this mutex simply. Is
> there any other way to protect it?

Right, that's a problem.  We'd need to either have a finer grained spin
lock (which we'd doubtless end up needing to hold for far too long so
probably won't work) or defer the list update to a workqueue or other
non-interrupt context which gets tricky.  Hrm...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140828/49bc2815/attachment.sig>