All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: hda codec unbind refcount hang
Date: Fri, 9 Sep 2022 22:39:19 +0300	[thread overview]
Message-ID: <YxuWZ/4+bKYChcge@intel.com> (raw)
In-Reply-To: <87fsh0czd8.wl-tiwai@suse.de>

On Fri, Sep 09, 2022 at 05:59:47PM +0200, Takashi Iwai wrote:
> On Fri, 09 Sep 2022 17:45:25 +0200,
> Ville Syrjälä wrote:
> > 
> > Hi Takashi,
> > 
> > commit 7206998f578d ("ALSA: hda: Fix potential deadlock at codec
> > unbinding") introduced a problem on at least one of my older machines.
> > 
> > The problem happens when hda_codec_driver_remove() encounters a
> > codec without any pcms (and thus the refcount is 1) and tries to
> > call refcount_dec(). Turns out refcount_dec() doesn't like to be
> > used for dropping the refcount to 0, and instead if spews a warning
> > and does its saturate thing. The subsequent wait_event() is then
> > permanently stuck waiting on the saturated refcount.
> > 
> > I've definitely seen the same kind of pattern used elsewhere
> > in the kernel as well, so the fact that refcount_t can't be used
> > to implement it is a bit of surprise to me. I guess most other
> > places still use atomic_t instead.
> 
> Does the patch below work around it?  It seem to be a subtle
> difference between refcount_dec() and refcount_dec_and_test().

Aye, this works.

Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> 
> 
> thanks,
> 
> Takashi
> 
> -- 8< --
> --- a/sound/pci/hda/hda_bind.c
> +++ b/sound/pci/hda/hda_bind.c
> @@ -157,10 +157,11 @@ static int hda_codec_driver_remove(struct device *dev)
>  		return codec->bus->core.ext_ops->hdev_detach(&codec->core);
>  	}
>  
> -	refcount_dec(&codec->pcm_ref);
> -	snd_hda_codec_disconnect_pcms(codec);
> -	snd_hda_jack_tbl_disconnect(codec);
> -	wait_event(codec->remove_sleep, !refcount_read(&codec->pcm_ref));
> +	if (!refcount_dec_and_test(&codec->pcm_ref)) {
> +		snd_hda_codec_disconnect_pcms(codec);
> +		snd_hda_jack_tbl_disconnect(codec);
> +		wait_event(codec->remove_sleep, !refcount_read(&codec->pcm_ref));
> +	}
>  	snd_power_sync_ref(codec->bus->card);
>  
>  	if (codec->patch_ops.free)

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-09-09 19:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09 15:45 hda codec unbind refcount hang Ville Syrjälä
2022-09-09 15:59 ` Takashi Iwai
2022-09-09 19:39   ` Ville Syrjälä [this message]
2022-09-10 10:22     ` Takashi Iwai
2022-09-10 11:54       ` Ville Syrjälä

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=YxuWZ/4+bKYChcge@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.