From patchwork Wed May 3 17:35:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amit Pundir X-Patchwork-Id: 98499 Delivered-To: patch@linaro.org Received: by 10.140.89.200 with SMTP id v66csp166186qgd; Wed, 3 May 2017 10:36:07 -0700 (PDT) X-Received: by 10.99.5.148 with SMTP id 142mr24468955pgf.104.1493832967428; Wed, 03 May 2017 10:36:07 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p20si12867632pli.35.2017.05.03.10.36.07; Wed, 03 May 2017 10:36:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752770AbdECRgG (ORCPT + 6 others); Wed, 3 May 2017 13:36:06 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:32899 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751880AbdECRgF (ORCPT ); Wed, 3 May 2017 13:36:05 -0400 Received: by mail-pg0-f44.google.com with SMTP id y4so76517172pge.0 for ; Wed, 03 May 2017 10:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=nmYFEWkaz0uWj4TRO03lfeyoekMbyq6I/MHC9kwNVsU=; b=T3xFs7pP0cJDcs0C71u7iBom1DsWXcBGpSFjQah86brululvSfzyEPzhZc043eXk0I etyPNQDNJ8czJfPC+WVbja/AMmeu9Ks9cl4RlgCk0x4Kd+/de8M0ta5sTS87JAuTxlH0 HF52zpkpjoUKcwu4zZWqc2yqn6UiVT610+CQM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=nmYFEWkaz0uWj4TRO03lfeyoekMbyq6I/MHC9kwNVsU=; b=V+2hK4s62u3gC1uFB2IUj+cXFskStYeuChVNx79Pg06d/uOsHRy13V2McNUXrPz9cT fi4bIXFy3IchsAPoa9i3rOnZxd/zNw4VB8zP/0hJDeXYecNLVDUpQLtFjm2JL/AIesze aUGAzq1I7A9+4gav8jv5iMtb8cRdpL8wiHGXbQMJ4K2VhVaMpe1cHB0jMBDPriKtgBDz pqlUjhTnuMJlgYb6Za7vm4bVaEquNVtgmvd79pvcghbsaQUuwO2iGKW4ihCD6ttJQFmI FfyDT9xqnRLWts1+p4YBEpsMZZD5/1qj86eQmXgzecDB+k7Ub1WwE4SA2pdDuJC2hie0 mHxQ== X-Gm-Message-State: AN3rC/69IreuzzMCWvpVlJrhLiqUQVTzkNz4dDggqol9z8bs6oQqMuMf kPLrbRjHN96Pi8N2 X-Received: by 10.84.128.66 with SMTP id 60mr51324698pla.167.1493832965231; Wed, 03 May 2017 10:36:05 -0700 (PDT) Received: from localhost.localdomain ([106.51.135.126]) by smtp.gmail.com with ESMTPSA id c3sm5895206pfg.46.2017.05.03.10.36.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 May 2017 10:36:04 -0700 (PDT) From: Amit Pundir To: Greg KH Cc: stable@vger.kernel.org, Takashi Iwai Subject: [PATCH for-3.18 1/7] ALSA: pcm : Call kill_fasync() in stream lock Date: Wed, 3 May 2017 23:05:52 +0530 Message-Id: <1493832958-12489-2-git-send-email-amit.pundir@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1493832958-12489-1-git-send-email-amit.pundir@linaro.org> References: <1493832958-12489-1-git-send-email-amit.pundir@linaro.org> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Takashi Iwai Currently kill_fasync() is called outside the stream lock in snd_pcm_period_elapsed(). This is potentially racy, since the stream may get released even during the irq handler is running. Although snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't guarantee that the irq handler finishes, thus the kill_fasync() call outside the stream spin lock may be invoked after the substream is detached, as recently reported by KASAN. As a quick workaround, move kill_fasync() call inside the stream lock. The fasync is rarely used interface, so this shouldn't have a big impact from the performance POV. Ideally, we should implement some sync mechanism for the proper finish of stream and irq handler. But this oneliner should suffice for most cases, so far. Reported-by: Baozeng Ding Signed-off-by: Takashi Iwai (cherry picked from commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4) Signed-off-by: Amit Pundir --- sound/core/pcm_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.7.4 diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index dfc28542a007..693ab89cc9a2 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1858,10 +1858,10 @@ void snd_pcm_period_elapsed(struct snd_pcm_substream *substream) if (substream->timer_running) snd_timer_interrupt(substream->timer, 1); _end: + kill_fasync(&runtime->fasync, SIGIO, POLL_IN); snd_pcm_stream_unlock_irqrestore(substream, flags); if (runtime->transfer_ack_end) runtime->transfer_ack_end(substream); - kill_fasync(&runtime->fasync, SIGIO, POLL_IN); } EXPORT_SYMBOL(snd_pcm_period_elapsed);