All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Daniel Mack <zonque@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Christof Meerwald <cmeerw@cmeerw.org>,
	"Artem S. Tashkinov" <t.artem@lycos.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>
Subject: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
Date: Thu, 08 Nov 2012 09:09:52 +0100	[thread overview]
Message-ID: <s5hr4o4frcf.wl%tiwai@suse.de> (raw)
In-Reply-To: <509B5FD7.3010609@gmail.com>

At Thu, 08 Nov 2012 08:31:35 +0100,
Daniel Mack wrote:
(snip)
> >> We can't simply stop both endpoints in the prepare callback.
> > 
> > The new function doesn't stop the stream by itself but it just syncs
> > if the stream is being stopped beforehand.  So, it's safe to call it
> > there.
> > 
> > Maybe the name was confusing.  It should have been like
> > snd_usb_endpoint_sync_pending_stop() or such.
> 
> Ah, right. I was errornously looking closer to Alan's patch but then
> replied to yours. Alright then - thanks for explaining :)

OK, thanks for checking.

FWIW, below is the patch I applied now to for-linus branch.
Renamed the function, added the comment and put NULL check to the
function to simplify.


Takashi

---
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: usb-audio: Fix crash at re-preparing the PCM stream

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 <t.artem@lycos.com>
Cc: <stable@vger.kernel.org> [v3.6]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/usb/endpoint.c | 13 +++++++++++++
 sound/usb/endpoint.h |  1 +
 sound/usb/pcm.c      |  3 +++
 3 files changed, 17 insertions(+)

diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index 7f78c6d..34de6f2 100644
--- 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_usb_endpoint *ep)
 	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.
  */
@@ -918,6 +929,8 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
 
 		if (wait)
 			wait_clear_urbs(ep);
+		else
+			set_bit(EP_FLAG_STOPPING, &ep->flags);
 	}
 }
 
diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
index 6376ccf..3d4c970 100644
--- a/sound/usb/endpoint.h
+++ b/sound/usb/endpoint.h
@@ -19,6 +19,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
 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);
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index 37428f7..5c12a3f 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -568,6 +568,9 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream)
 		goto unlock;
 	}
 
+	snd_usb_endpoint_sync_pending_stop(subs->sync_endpoint);
+	snd_usb_endpoint_sync_pending_stop(subs->data_endpoint);
+
 	ret = set_format(subs, subs->cur_audiofmt);
 	if (ret < 0)
 		goto unlock;
-- 
1.8.0



  reply	other threads:[~2012-11-08  8:09 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-20 12:06 A reliable kernel panic (3.6.2) and system crash when visiting a particular website Artem S. Tashkinov
2012-10-20 16:27 ` Borislav Petkov
2012-10-20 17:41   ` Artem S. Tashkinov
2012-10-20 18:04     ` Borislav Petkov
2012-10-20 20:57       ` Artem S. Tashkinov
2012-10-20 22:00       ` Artem S. Tashkinov
2012-10-20 20:32     ` Pavel Machek
2012-10-20 22:58       ` Borislav Petkov
2012-10-20 23:15         ` Artem S. Tashkinov
2012-10-21  0:24           ` Borislav Petkov
2012-10-21  0:24             ` Borislav Petkov
2012-10-21  1:57             ` Artem S. Tashkinov
2012-10-21 11:08               ` Borislav Petkov
2012-10-21 11:59                 ` Artem S. Tashkinov
2012-10-21 12:03                   ` Daniel Mack
2012-10-21 12:03                     ` Daniel Mack
2012-10-21 12:30                     ` Artem S. Tashkinov
2012-10-21 12:30                       ` Artem S. Tashkinov
2012-10-21 14:21                       ` was: " Daniel Mack
2012-10-21 14:57                         ` Artem S. Tashkinov
2012-10-21 15:22                           ` Daniel Mack
2012-10-21 15:28                             ` Alan Stern
2012-10-21 15:28                               ` Alan Stern
2012-10-21 15:36                               ` Daniel Mack
2012-10-21 12:12                   ` Daniel Mack
2012-10-21 15:23                   ` Re: Re: Re: " Alan Stern
2012-10-21 22:20                     ` A strange Linux 3.6 bug: corrupted page table Artem S. Tashkinov
2012-10-21 17:03                   ` Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website Borislav Petkov
2012-10-21 19:49                     ` Artem S. Tashkinov
2012-10-21 19:54                       ` Daniel Mack
2012-10-21 20:43                         ` Artem S. Tashkinov
2012-10-21 21:00                           ` Daniel Mack
2012-10-21 21:00                             ` Daniel Mack
2012-10-21 20:36                       ` Re: Re: Re: Re: " Borislav Petkov
2012-10-22 15:17                       ` Alan Stern
2012-10-22 15:17                         ` Alan Stern
2012-10-22 15:30                         ` Daniel Mack
2012-10-22 15:54                           ` Alan Stern
2012-10-22 15:54                             ` Alan Stern
2012-10-22 17:30                             ` Artem S. Tashkinov
2012-10-22 18:01                               ` Alan Stern
2012-10-22 18:01                                 ` Alan Stern
2012-10-21  2:19           ` Alan Stern
2012-10-21 10:34           ` Daniel Mack
2012-10-21 11:59             ` Daniel Mack
2012-11-03 14:10           ` Christof Meerwald
2012-11-03 14:16             ` Daniel Mack
2012-11-03 14:28               ` Sven-Haegar Koch
2012-11-05 19:13               ` Christof Meerwald
2012-11-07 17:34                 ` Alan Stern
2012-11-07 19:19                   ` Takashi Iwai
2012-11-07 20:37                     ` Alan Stern
2012-11-08  6:48                       ` Takashi Iwai
2012-11-07 20:46                     ` Christof Meerwald
2012-11-07 20:59                     ` Artem S. Tashkinov
2012-11-08  0:42                     ` Daniel Mack
2012-11-08  6:43                       ` Takashi Iwai
2012-11-08  7:31                         ` Daniel Mack
2012-11-08  8:09                           ` Takashi Iwai [this message]
2012-11-08 15:55                             ` Alan Stern
2012-11-08 15:58                               ` Takashi Iwai

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=s5hr4o4frcf.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=cmeerw@cmeerw.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=t.artem@lycos.com \
    --cc=zonque@gmail.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 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.