Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3620970imu; Mon, 14 Jan 2019 06:18:11 -0800 (PST) X-Google-Smtp-Source: ALg8bN7kavAEle18DWucI6fEkpozoXVZiCF/ohRv5k3ep2c0KQv18f5m9fAK3eB6YRoOJnCJDOht X-Received: by 2002:a17:902:b90b:: with SMTP id bf11mr25333861plb.284.1547475491685; Mon, 14 Jan 2019 06:18:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547475491; cv=none; d=google.com; s=arc-20160816; b=lZaSF8H8N53I2fYkxn0fd8/ic3kC+7TDex8XvRnzxh69jL9g5nilth2oF1a9y5/rcd 6GXsgbW0P5kw3+u57WbDPqt3dx6mB5bHV9Ig7eUCiVOmTXIZDTAjxhMLqux8tNDXW9S4 Sq3vQHb7ZaVb4DS0S98++5DFkgXjvBLGFi7VWt0yDNrTZvtltEhJ2OWLqiN7VAPtOk4L GV8VW7xmUETqtt1OhpVWciL1ApvqlvhW2mJNFFrp04EMKeY1GewUew5KeTRZgbai5rFc I5GxsJb3VV5UnMvoJmGgU6BBL15K7hMhgSZiTqzyEDWZj2G1xzQ8378hrFwHwMfAqBov fDfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=7/ymgJLtY2CmeKovMxkVEIwIQ8Xgky8Zc1Zfauk6W9g=; b=AYaQMCiJPUu5Hjx/9HyIKs7zM2mzYrmiWOOh+l2NwP+mHmy7c9vOOc8D2RV/9cb+qC Z4MuYYrbpgbM1ElrunTYQWSv+jjNQTqizW5ETmXT/s8/QdyF4qhbIN6oa6IU+ZQLFYYV NeBSTq3U4OkKot30Dzi8LoeqOI3u0X2kmtCyNe+sTYWpO6+U6qJsipa3yAkaBnjyrhOE FFrtXcFee0F5x+xSD/jrFVIzzgqoPT6fLAgtbZWPYpx0Ks+4aM47wSi9eR74V1ipV5BF 8cUUIKRJr4JZtMmCYlko0BFkuWUh4rDtbPdKCoRZQvDXZ9IhRvojyDZ+ba93sjhvOy1i SKeg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t6si426996plz.96.2019.01.14.06.17.55; Mon, 14 Jan 2019 06:18:11 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726609AbfANOQu (ORCPT + 99 others); Mon, 14 Jan 2019 09:16:50 -0500 Received: from foss.arm.com ([217.140.101.70]:34642 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726482AbfANOQu (ORCPT ); Mon, 14 Jan 2019 09:16:50 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CEA66A78; Mon, 14 Jan 2019 06:16:49 -0800 (PST) Received: from [10.1.196.75] (e110467-lin.cambridge.arm.com [10.1.196.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DC3DB3F5AF; Mon, 14 Jan 2019 06:16:47 -0800 (PST) Subject: Re: [PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM To: Christoph Hellwig , Pawel Osciak , Marek Szyprowski , Kyungmin Park , =?UTF-8?Q?Niklas_S=c3=b6derlund?= Cc: Russell King , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Mauro Carvalho Chehab , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org References: <20190111181731.11782-1-hch@lst.de> <20190111181731.11782-3-hch@lst.de> From: Robin Murphy Message-ID: Date: Mon, 14 Jan 2019 14:16:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190111181731.11782-3-hch@lst.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/01/2019 18:17, Christoph Hellwig wrote: > Use WARN_ON_ONCE to print a stack trace and return a proper error > code instead. I was racking my brain to remember the reasoning behind BUG_ON() being the only viable way to prevent errors getting through unhandled, but of course that was before we had a standardised DMA_MAPPING_ERROR that would work across all implementations. > Signed-off-by: Christoph Hellwig > --- > include/linux/dma-mapping.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index d3087829a6df..91add0751aa5 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -353,7 +353,8 @@ static inline dma_addr_t dma_map_resource(struct device *dev, > BUG_ON(!valid_dma_direction(dir)); > > /* Don't allow RAM to be mapped */ Ugh, I'm pretty sure that that "pfn_valid means RAM" misunderstanding originally came from me - it might be nice to have a less-misleading comment here, but off-hand I can't think of a succinct way to say "only for 'DMA' access to MMIO registers/SRAMs/etc. and not for anything the kernel knows as actual system/device memory" to better explain the WARN... Either way, though, Reviewed-by: Robin Murphy > - BUG_ON(pfn_valid(PHYS_PFN(phys_addr))); > + if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) > + return DMA_MAPPING_ERROR; > > if (dma_is_direct(ops)) > addr = dma_direct_map_resource(dev, phys_addr, size, dir, attrs); >