Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
Cc: alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.com>
Subject: Re: [PATCH] ALSA: jack: Access input_dev under mutex
Date: Thu, 07 Apr 2022 10:24:57 +0200	[thread overview]
Message-ID: <s5hk0c12td2.wl-tiwai@suse.de> (raw)
In-Reply-To: <20220401122931.4181700-1-amadeuszx.slawinski@linux.intel.com>

On Fri, 01 Apr 2022 14:29:31 +0200,
Amadeusz Sławiński wrote:
> 
> @@ -517,11 +525,15 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
>  		return -ENOMEM;
>  	}
>  
> -	/* don't creat input device for phantom jack */
> -	if (!phantom_jack) {
>  #ifdef CONFIG_SND_JACK_INPUT_DEV
> +	mutex_init(&jack->input_dev_lock);
> +
> +	/* don't create input device for phantom jack */
> +	if (!phantom_jack) {
>  		int i;
>  
> +		mutex_lock(&jack->input_dev_lock);
> +

This lock is superfluous.  The object is being created here and isn't
registered anywhere, so no one else can use it yet.
And moreover ....

>  		jack->input_dev = input_allocate_device();
>  		if (jack->input_dev == NULL) {
>  			err = -ENOMEM;

... you forgot unlock here, and this error path will lead to a
deadlock.


> @@ -537,8 +549,9 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
>  				input_set_capability(jack->input_dev, EV_SW,
>  						     jack_switch_types[i]);
>  
> -#endif /* CONFIG_SND_JACK_INPUT_DEV */
> +		mutex_unlock(&jack->input_dev_lock);
>  	}
> +#endif /* CONFIG_SND_JACK_INPUT_DEV */
>  
>  	err = snd_device_new(card, SNDRV_DEV_JACK, jack, &ops);
>  	if (err < 0)
> @@ -556,7 +569,9 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
>  
>  fail_input:
>  #ifdef CONFIG_SND_JACK_INPUT_DEV
> +	mutex_lock(&jack->input_dev_lock);
>  	input_free_device(jack->input_dev);
> +	mutex_unlock(&jack->input_dev_lock);

Ditto, no need for mutex lock yet.

One thing I'm not sure is whether it's good to use mutex.
Basically snd_jack_report() is considered to be callable from
non-atomic context, too, so far, and we don't need to prohibit it.
OTOH, all current calls are in the sleepable context, so it's likely
no big problem.  But if we use mutex, it should be documented in
snd_jack_report() function, too.


thanks,

Takashi

      parent reply	other threads:[~2022-04-07  8:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-01 12:29 [PATCH] ALSA: jack: Access input_dev under mutex Amadeusz Sławiński
2022-04-01 13:03 ` Cezary Rojewski
2022-04-07  8:24 ` Takashi Iwai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hk0c12td2.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox