Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp236763yba; Fri, 3 May 2019 00:25:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+e93ze81Uh8Cqx+ckYuzV5yRVX2O9zvR82IWS7nK6hDdr/IKaHjVkz3na4m3OZy40e8vj X-Received: by 2002:a17:902:a614:: with SMTP id u20mr8442694plq.117.1556868332154; Fri, 03 May 2019 00:25:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556868332; cv=none; d=google.com; s=arc-20160816; b=rfIvPPF6wCItlEVHU/UN/d2VUOG2Xf7hZa3ooVngwdPaqbxn49Wfgcz9r9ENDGSKIh 2oF9GkizQaBpM45LzcQv/jxBSepgC1t/t4LE48T7jCbDkgO3YhNtFeupZnXqp4RQ+e1j 2HkpJ8ynWk0n8vhX0lpf0fXZ1zcIPXSa7y7WdS39VAvaQ89j/Dc0UmBEiGc+lnNNLFTi 0VG0CjDurjYRRCfMtHFZEGcZUccM2jLxZxE/XPk9bwXmZR3ITZs7ay5jT0BFZZK4hVuD 2xosH1xQlyXggl6+PbCVGOrTRsWnCEJQ6BhSW+wAaEAvTqDq9ycFJAAbNnEz8pEhPbpR gQPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:in-reply-to:subject:cc:to :from:dkim-signature; bh=ZQwUU+J/MQcrEGIy0MJ+HGRMeveOuqWSbA/IkAltfgs=; b=ta7hQsASOJ3fmcvWR1kUaIclRKiZgXyXH/YKzau28G5F1E+fYK6jggCvgjXHFr7sGx +khw2/27kabzR0fvnO57Y21DT9+KcrejAVbYc/EFOOECHWf3UfHVXgmk4TziuuOxKZUZ i1yJlGnsXMQta9Nv2Uj8/PU9994I9C7lOthy2AnDPGJoQWFM8qTlWGAhxqmKKYabRqA1 vD7Behi9oJvBK08ERfLY4B3Uoyvmo7n+FFBxntF2LBNM332+1txaaKt/8Jx5kqk8XRA/ 6Di9XwOeJ8tuIAfcquExTXkDvi6A2v8brNOnex/UhIKnzhznjy9EKV61FRUJ67wrMafo CXrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=qWrCcM5m; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r9si1429755pls.323.2019.05.03.00.25.16; Fri, 03 May 2019 00:25:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=qWrCcM5m; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727111AbfECGYj (ORCPT + 99 others); Fri, 3 May 2019 02:24:39 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:33632 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727002AbfECGXq (ORCPT ); Fri, 3 May 2019 02:23:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Date:Message-Id:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=ZQwUU+J/MQcrEGIy0MJ+HGRMeveOuqWSbA/IkAltfgs=; b=qWrCcM5maPcy rJLp3VUSxkK7tfwySdkal5afdLPPDqqWT2HKlVJVLpiBQlSdhiBKVHamf24PUPMuivhQwwss+ZOty Mx6TblpdBmUkn+5Kl/u8f0d4Vm0HLcXXFD0yuKpi/ZF8PzZK7TBGW2ty9sGgmWTnAJ3OoNRHhGmtb 3yZH8=; Received: from [42.29.24.106] (helo=finisterre.ee.mobilebroadband) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hMRb8-0000bh-6o; Fri, 03 May 2019 06:23:06 +0000 Received: by finisterre.ee.mobilebroadband (Postfix, from userid 1000) id EDBA1441D67; Fri, 3 May 2019 07:21:29 +0100 (BST) From: Mark Brown To: Ross Zwisler Cc: alsa-devel@alsa-project.org, Jaroslav Kysela , Jie Yang , Liam Girdwood , linux-kernel@vger.kernel.org, Mark Brown , Pierre-Louis Bossart , Ross Zwisler , stable@vger.kernel.org, Takashi Iwai Subject: Applied "ASoC: Intel: avoid Oops if DMA setup fails" to the asoc tree In-Reply-To: <20190429182517.210909-1-zwisler@google.com> X-Patchwork-Hint: ignore Message-Id: <20190503062129.EDBA1441D67@finisterre.ee.mobilebroadband> Date: Fri, 3 May 2019 07:21:29 +0100 (BST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The patch ASoC: Intel: avoid Oops if DMA setup fails has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.2 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark From 0efa3334d65b7f421ba12382dfa58f6ff5bf83c4 Mon Sep 17 00:00:00 2001 From: Ross Zwisler Date: Mon, 29 Apr 2019 12:25:17 -0600 Subject: [PATCH] ASoC: Intel: avoid Oops if DMA setup fails Currently in sst_dsp_new() if we get an error return from sst_dma_new() we just print an error message and then still complete the function successfully. This means that we are trying to run without sst->dma properly set up, which will result in NULL pointer dereference when sst->dma is later used. This was happening for me in sst_dsp_dma_get_channel(): struct sst_dma *dma = dsp->dma; ... dma->ch = dma_request_channel(mask, dma_chan_filter, dsp); This resulted in: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: sst_dsp_dma_get_channel+0x4f/0x125 [snd_soc_sst_firmware] Fix this by adding proper error handling for the case where we fail to set up DMA. This change only affects Haswell and Broadwell systems. Baytrail systems explicilty opt-out of DMA via sst->pdata->resindex_dma_base being set to -1. Signed-off-by: Ross Zwisler Cc: stable@vger.kernel.org Acked-by: Pierre-Louis Bossart Signed-off-by: Mark Brown --- sound/soc/intel/common/sst-firmware.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/common/sst-firmware.c b/sound/soc/intel/common/sst-firmware.c index 1e067504b604..f830e59f93ea 100644 --- a/sound/soc/intel/common/sst-firmware.c +++ b/sound/soc/intel/common/sst-firmware.c @@ -1251,11 +1251,15 @@ struct sst_dsp *sst_dsp_new(struct device *dev, goto irq_err; err = sst_dma_new(sst); - if (err) - dev_warn(dev, "sst_dma_new failed %d\n", err); + if (err) { + dev_err(dev, "sst_dma_new failed %d\n", err); + goto dma_err; + } return sst; +dma_err: + free_irq(sst->irq, sst); irq_err: if (sst->ops->free) sst->ops->free(sst); -- 2.20.1