Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp193431yba; Thu, 2 May 2019 23:22:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqzYgLUrjmUsfgp/w5h2Kty251tjPm51GXwAdvU4w3raZi8TYCtZzG2zpWmQQzeruxz1Q7Cn X-Received: by 2002:a17:902:42:: with SMTP id 60mr8219035pla.79.1556864554885; Thu, 02 May 2019 23:22:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556864554; cv=none; d=google.com; s=arc-20160816; b=Et52boG+5GJow+C+jcU44OPJrVjw2/VyAbO/WKti5wzViAOzXl5r3+3pMVQSVcZznI 2PMQk1ePD7i5xDJErSvFoQHrFY8b7O1R7ZUyLcEMZ6BXZedLCAphYvG4wLljwIQ0/DzG ciuFO+rXwkLM8g+IH+tclkPU8ZlB+8V4/QGXlVN8ppw92ARhVUGwB2LsJ5z1f42DKDHi 5DUqHhNHxUqxpTWW/90mQz5DZvoT2IX2Aj2zKNJvYq27N5clmfsMoLcVHTvWzpweOj/Z R6jc5BQYjYqym23K/SyhwWmD6aJW02lfS37bU9MKVLSlhkxOA8DVUE1vx+YfXfaphb3Y p2Gg== 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=DW080cgKpYTtS//CgKGJFmTk9T16Wc5ra0pGbWJ5Go5NhnI2g1Yi70kcsra79HXRRF kIyLhyy56E7gMvPcmCQJvwmG31E5UjgsH5Fasgi0OybvG01oQ19LJoRazHqdEA5CNC13 iBAKOAw6jR/Z0f5UUhwGK2FR/rX0I1xOVLFj92tIN8L3NMfW+dTomN9o8vMhlPUmUT/+ 0WEKUzjhwBlm6e0lTaudkYwBPiUt6W/SpJ9+cfbzNGcTDlC9DfsyFwuhNYsnKS4DveoQ JngDVRfiaVW0oJ/LM0Dp1kyXbCIdF0lFD6FCKhUc1h8X51ek/DK4tvi8T+6kQKxLITIV FKSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=dBcYRvUe; 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 i9si1139761pgs.402.2019.05.02.23.22.19; Thu, 02 May 2019 23:22:34 -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=dBcYRvUe; 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 S1726817AbfECGS6 (ORCPT + 99 others); Fri, 3 May 2019 02:18:58 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:53074 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726743AbfECGS5 (ORCPT ); Fri, 3 May 2019 02:18:57 -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=dBcYRvUe1aCP YZGZsViJliQgDvfMwTe4+d113vEp7lkGUS7j9+9b0hacgeOKj4nV6j9rfXymYydE48ER93PKLjne8 5qNi67Fq6TvXnRW3RgKVYGbLeTHwwcLOrvQLTtKF6W3JccRjWJHGdmelTC9HnbavV/QJf5lKY4KJE icsyw=; 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 1hMRWw-0000Wg-Oi; Fri, 03 May 2019 06:18:47 +0000 Received: by finisterre.ee.mobilebroadband (Postfix, from userid 1000) id 6D839441D58; Fri, 3 May 2019 07:18:42 +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: <20190503061842.6D839441D58@finisterre.ee.mobilebroadband> Date: Fri, 3 May 2019 07:18:42 +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