From patchwork Fri Sep 1 10:25:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Takashi Sakamoto X-Patchwork-Id: 9933855 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 962B86038C for ; Fri, 1 Sep 2017 10:25:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 88DE72862A for ; Fri, 1 Sep 2017 10:25:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 77D522863B; Fri, 1 Sep 2017 10:25:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 977E828631 for ; Fri, 1 Sep 2017 10:25:58 +0000 (UTC) Received: from alsa0.perex.cz (localhost [127.0.0.1]) by alsa0.perex.cz (Postfix) with ESMTP id 172AC2676AD; Fri, 1 Sep 2017 12:25:47 +0200 (CEST) X-Original-To: alsa-devel@alsa-project.org Delivered-To: alsa-devel@alsa-project.org Received: by alsa0.perex.cz (Postfix, from userid 1000) id 806F22676AF; Fri, 1 Sep 2017 12:25:46 +0200 (CEST) Received: from smtp-proxy002.phy.lolipop.jp (smtp-proxy002.phy.lolipop.jp [157.7.104.43]) by alsa0.perex.cz (Postfix) with ESMTP id 6C3DF266DBC for ; Fri, 1 Sep 2017 12:25:41 +0200 (CEST) Received: from smtp-proxy002.phy.lolipop.lan (HELO smtp-proxy002.phy.lolipop.jp) (172.19.44.43) (smtp-auth username m12129643-o-takashi, mechanism plain) by smtp-proxy002.phy.lolipop.jp (qpsmtpd/0.82) with ESMTPA; Fri, 01 Sep 2017 19:25:39 +0900 Received: from 127.0.0.1 (127.0.0.1) by smtp-proxy002.phy.lolipop.jp (LOLIPOP-Fsecure); Fri, 01 Sep 2017 19:25:37 +0900 (JST) X-Virus-Status: clean(LOLIPOP-Fsecure) From: Takashi Sakamoto To: tiwai@suse.de, perex@perex.cz, anna-maria@linutronix.de Date: Fri, 1 Sep 2017 19:25:37 +0900 Message-Id: <20170901102537.8066-1-o-takashi@sakamocchi.jp> X-Mailer: git-send-email 2.11.0 In-Reply-To: References: Cc: alsa-devel@alsa-project.org, keescook@chromium.org, peterz@infradead.org, linux-kernel@vger.kernel.org, mingo@redhat.com, john.stultz@linaro.org, tglx@linutronix.de, hch@lst.org Subject: Re: [alsa-devel] [PATCH 23/25] ALSA/dummy: Replace tasklet with softirq hrtimer X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On Sep 1 2017 00:36, Takashi Iwai wrote: > I gave it at try, but it caused a kernel hang, unfortunately. > > The reason is that snd_pcm_period_elapased() may stop the stream > (e.g. when reaching at the end). With this patchset, it'll lead to > the call of hrtimer_cancel() from the hrtimer callback itself, thus it > stalls. I can reproduce this bug. > Below is the additional fix over your patch for working around it. > I believe it should cover most corner cases, and seems working fine > through quick tests, so far. This patch looks good to me, too. But I have an alternative. We can use 'hrtimer_callback_running()' to detect whether to be on hrtimer callback or not (please read '__run_hrtimer()' in 'kernel/time/hrtimer.c'). Usage of this helper function on .stop callback to skip cancellation can avoid the stall. In this case, after stopping PCM substream, the hrtimer callback should return HRTIMER_NORESTART to avoid restarting, as well as your patch. Please test a patch in this message. > --- > diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c > index 273d60c42125..b5dd64e3dab1 100644 > --- a/sound/drivers/dummy.c > +++ b/sound/drivers/dummy.c > @@ -375,6 +375,7 @@ struct dummy_hrtimer_pcm { > ktime_t base_time; > ktime_t period_time; > atomic_t running; > + atomic_t callback_running; > struct hrtimer timer; > struct snd_pcm_substream *substream; > }; > @@ -387,8 +388,15 @@ static enum hrtimer_restart dummy_hrtimer_callback(struct hrtimer *timer) > if (!atomic_read(&dpcm->running)) > return HRTIMER_NORESTART; > > + atomic_inc(&dpcm->callback_running); > snd_pcm_period_elapsed(dpcm->substream); > + atomic_dec(&dpcm->callback_running); > + /* may be flipped during snd_pcm_period_elapsed() */ > + if (!atomic_read(&dpcm->running)) > + return HRTIMER_NORESTART; > + > hrtimer_forward_now(timer, dpcm->period_time); > + atomic_dec(&dpcm->callback_running); > return HRTIMER_RESTART; > } > > @@ -407,7 +415,9 @@ static int dummy_hrtimer_stop(struct snd_pcm_substream *substream) > struct dummy_hrtimer_pcm *dpcm = substream->runtime->private_data; > > atomic_set(&dpcm->running, 0); > - hrtimer_cancel(&dpcm->timer); > + /* issue hrtimer_cancel() only when called outside the callback */ > + if (!atomic_read(&dpcm->callback_running)) > + hrtimer_cancel(&dpcm->timer); > return 0; > } > > @@ -462,6 +472,7 @@ static int dummy_hrtimer_create(struct snd_pcm_substream *substream) > dpcm->timer.function = dummy_hrtimer_callback; > dpcm->substream = substream; > atomic_set(&dpcm->running, 0); > + atomic_set(&dpcm->callback_running, 0); > return 0; > } From 07d61ba2a1c0e06e914443225e194d99f2d8c58d Mon Sep 17 00:00:00 2001 From: Takashi Sakamoto Date: Fri, 1 Sep 2017 19:10:18 +0900 Subject: [PATCH] ALSA: dummy: avoid stall due to a call of hrtimer_cancel() on a callback of hrtimer A call of 'htrimer_cancel()' on a callback of hrtimer brings endless loop because 'struct hrtimer_clock_base.running' is not NULL on the callback. In hrtimer subsystem, this member is used to indicate the instance of hrtimer gets callbacks and there's a helper function, 'hrtimer_callback_running()' to check it. ALSA dummy driver uses hrtimer to emulate hardware interrupt per period of PCM buffer. When XRUN occurs on PCM substream, in a call of 'snd_pcm_period_elapsed()', 'struct snd_pcm_ops.stop()' is called to stop the substream. In current implementation, 'hrtimer_cancel()' is used to wait for cancellation of hrtimer. However, as described, this brings endless loop. For this problem, this commit uses 'hrtimer_callback_running()' to detect whether to be on a callback of hrtimer or not, then skip cancellation of hrtimer in hrtimer callbacks. Furthermore, at a case of XRUN, hrtimer callback returns HRTIMER_NORESTART after a call of 'snd_pcm_period_elapsed()' to discontinue hrtimr because cancellation is skipped. Signed-off-by: Takashi Sakamoto --- sound/drivers/dummy.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c index 273d60c42125..9caf754c6135 100644 --- a/sound/drivers/dummy.c +++ b/sound/drivers/dummy.c @@ -387,7 +387,11 @@ static enum hrtimer_restart dummy_hrtimer_callback(struct hrtimer *timer) if (!atomic_read(&dpcm->running)) return HRTIMER_NORESTART; + /* In a case of XRUN, this calls .trigger to stop PCM substream. */ snd_pcm_period_elapsed(dpcm->substream); + if (!atomic_read(&dpcm->running)) + return HRTIMER_NORESTART; + hrtimer_forward_now(timer, dpcm->period_time); return HRTIMER_RESTART; } @@ -407,7 +411,8 @@ static int dummy_hrtimer_stop(struct snd_pcm_substream *substream) struct dummy_hrtimer_pcm *dpcm = substream->runtime->private_data; atomic_set(&dpcm->running, 0); - hrtimer_cancel(&dpcm->timer); + if (!hrtimer_callback_running(&dpcm->timer)) + hrtimer_cancel(&dpcm->timer); return 0; }