From: <gregkh@linuxfoundation.org>
To: tiwai@suse.de, stable@vger.kernel.org, ville.syrjala@linux.intel.com
Cc: <stable@vger.kernel.org>
Subject: FAILED: patch "[PATCH] ALSA: hda: Fix hang at HD-audio codec unbinding due to" failed to apply to 5.15-stable tree
Date: Fri, 23 Sep 2022 19:33:14 +0200 [thread overview]
Message-ID: <166395439470255@kroah.com> (raw)
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Possible dependencies:
ead3d3c5b54f ("ALSA: hda: Fix hang at HD-audio codec unbinding due to refcount saturation")
37c4fd0db7c9 ("ALSA: hda: Do disconnect jacks at codec unbind")
7206998f578d ("ALSA: hda: Fix potential deadlock at codec unbinding")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ead3d3c5b54f76da79c079e61bacb4279ec56965 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Sat, 10 Sep 2022 16:25:50 +0200
Subject: [PATCH] ALSA: hda: Fix hang at HD-audio codec unbinding due to
refcount saturation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We fixed the potential deadlock at dynamic unbinding the HD-audio
codec at the commit 7206998f578d ("ALSA: hda: Fix potential deadlock
at codec unbinding"), but ironically, this caused another potential
deadlock. The current code uses refcount_dec() and waits for the
pending task with wait_event for dropping the refcount to 0. This
works fine when PCMs are assigned and actually waiting for the
refcount drop.
Meanwhile, when there was no PCM assigned, the refcount_dec() call
itself was supposed to drop to zero -- alas, it doesn't in reality;
refcount_dec() complains, spews kernel warning and it saturates
instead of dropping to 0, due to the nature of refcount_dec()
implementation. This eventually blocks the wait_event() wakeup and
the code get stuck there.
For avoiding the problem, we call refcount_dec_and_test() and skips
the sync-wait if it already reaches to zero.
The patch does a slight code reshuffling to make sure to invoke other
disconnect calls before the sync-wait, too.
Fixes: 7206998f578d ("ALSA: hda: Fix potential deadlock at codec unbinding")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/YxtflWQnslMHVlU7@intel.com
Link: https://lore.kernel.org/r/20220910142550.28494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c
index cae9a975cbcc..1a868dd9dc4b 100644
--- a/sound/pci/hda/hda_bind.c
+++ b/sound/pci/hda/hda_bind.c
@@ -157,10 +157,10 @@ 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))
+ wait_event(codec->remove_sleep, !refcount_read(&codec->pcm_ref));
snd_power_sync_ref(codec->bus->card);
if (codec->patch_ops.free)
reply other threads:[~2022-09-23 17:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=166395439470255@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--cc=tiwai@suse.de \
--cc=ville.syrjala@linux.intel.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