Hi,
On Mon, 15 Apr 2019, Takashi Iwai wrote:
> > > +void snd_seq_client_ioctl_unlock(int clientid)
> > > +{
> > > + struct snd_seq_client *client;
> > > +
> > > + client = snd_seq_client_use_ptr(clientid);
> > > + if (WARN_ON(!client))
> > > + return;
> > > + mutex_unlock(&client->ioctl_mutex);
> > > + snd_use_lock_free(&client->use_lock);
> > > + snd_seq_client_unlock(client);
> >
> > is that double-unlock intentional? snd_seq_client_unlock() seems to call
> > the same snd_use_lock_free for the same handle as on the previous line.
>
> Yes, it's intentional. The trick is snd_seq_client_ioctl_lock()
> doesn't call snd_seq_client_unlock(), i.e. keeps refcount up. This
> is, in turn, released in snd_seq_client_ioctl_unlock().
> snd_seq_client_ioctl_unlock() gets its refcount at use_ptr(), hence
> this releases twice. Maybe it's worth for more comments.
ah yes, ok thanks, just checking. :) I was misled by the asymmetric
names. As you are taking the refcount with two client_use_ptr() calls in
both lock and unlock, would it be more logical to have two
snd_seq_client_unlock() calls in unlock?
Otherwise patchset looks good!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
