This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Fix crash at re-preparing the PCM stream
to the 3.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
alsa-usb-audio-fix-crash-at-re-preparing-the-pcm-stream.patch
and it can be found in the queue-3.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From [email protected] Tue Nov 20 10:52:09 2012
From: Takashi Iwai <[email protected]>
Date: Tue, 20 Nov 2012 08:20:02 +0100
Subject: ALSA: usb-audio: Fix crash at re-preparing the PCM stream
To: <[email protected]>
From: Takashi Iwai <[email protected]>
commit f58161ba1b05a968e5136824b5a16b714b6a5317 upstream.
There are bug reports of a crash with USB-audio devices when PCM
prepare is performed immediately after the stream is stopped via
trigger callback. It turned out that the problem is that we don't
wait until all URBs are killed.
This patch adds a new function to synchronize the pending stop
operation on an endpoint, and calls in the prepare callback for
avoiding the crash above.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=49181
Reported-and-tested-by: Artem S. Tashkinov <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/usb/endpoint.c | 13 +++++++++++++
sound/usb/endpoint.h | 1 +
sound/usb/pcm.c | 3 +++
3 files changed, 17 insertions(+)
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -35,6 +35,7 @@
#define EP_FLAG_ACTIVATED 0
#define EP_FLAG_RUNNING 1
+#define EP_FLAG_STOPPING 2
/*
* snd_usb_endpoint is a model that abstracts everything related to an
@@ -502,10 +503,20 @@ static int wait_clear_urbs(struct snd_us
if (alive)
snd_printk(KERN_ERR "timeout: still %d active urbs on EP #%x\n",
alive, ep->ep_num);
+ clear_bit(EP_FLAG_STOPPING, &ep->flags);
return 0;
}
+/* sync the pending stop operation;
+ * this function itself doesn't trigger the stop operation
+ */
+void snd_usb_endpoint_sync_pending_stop(struct snd_usb_endpoint *ep)
+{
+ if (ep && test_bit(EP_FLAG_STOPPING, &ep->flags))
+ wait_clear_urbs(ep);
+}
+
/*
* unlink active urbs.
*/
@@ -913,6 +924,8 @@ void snd_usb_endpoint_stop(struct snd_us
if (wait)
wait_clear_urbs(ep);
+ else
+ set_bit(EP_FLAG_STOPPING, &ep->flags);
}
}
--- a/sound/usb/endpoint.h
+++ b/sound/usb/endpoint.h
@@ -16,6 +16,7 @@ int snd_usb_endpoint_set_params(struct s
int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
int force, int can_sleep, int wait);
+void snd_usb_endpoint_sync_pending_stop(struct snd_usb_endpoint *ep);
int snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
int snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep);
void snd_usb_endpoint_free(struct list_head *head);
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -563,6 +563,9 @@ static int snd_usb_pcm_prepare(struct sn
goto unlock;
}
+ snd_usb_endpoint_sync_pending_stop(subs->sync_endpoint);
+ snd_usb_endpoint_sync_pending_stop(subs->data_endpoint);
+
/* some unit conversions in runtime */
subs->data_endpoint->maxframesize =
bytes_to_frames(runtime, subs->data_endpoint->maxpacksize);
Patches currently in stable-queue which might be from [email protected] are
queue-3.6/alsa-hda-add-a-missing-quirk-entry-for-imac-9-1.patch
queue-3.6/alsa-usb-audio-fix-crash-at-re-preparing-the-pcm-stream.patch
queue-3.6/alsa-hda-fix-invalid-connections-in-vt1802-codec.patch
queue-3.6/alsa-hda-improve-hp-depop-when-system-enter-to-s3.patch
queue-3.6/alsa-hda-fix-empty-dac-filling-in-patch_via.c.patch
queue-3.6/alsa-hda-force-to-reset-iec958-status-bits-for-ad-codecs.patch
queue-3.6/alsa-hda-fix-digital-microphone-on-cs420x.patch
queue-3.6/alsa-hda-add-new-codec-alc668-and-alc900-default-name-alc1150.patch
queue-3.6/alsa-hda-cirrus-fix-coefficient-index-for-beep-configuration.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
