From: Robin Murphy <robin.murphy@arm.com> To: "Christoph Hellwig" <hch@lst.de>, "Pawel Osciak" <pawel@osciak.com>, "Marek Szyprowski" <m.szyprowski@samsung.com>, "Kyungmin Park" <kyungmin.park@samsung.com>, "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se> Cc: Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Mauro Carvalho Chehab <mchehab@kernel.org>, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Subject: Re: [PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM Date: Mon, 14 Jan 2019 14:16:46 +0000 [thread overview] Message-ID: <f8f9e4f0-87fc-9f4f-37ea-39297acc8d31@arm.com> (raw) In-Reply-To: <20190111181731.11782-3-hch@lst.de> 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 <hch@lst.de> > --- > 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 <robin.murphy@arm.com> > - 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); >
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: "Christoph Hellwig" <hch@lst.de>, "Pawel Osciak" <pawel@osciak.com>, "Marek Szyprowski" <m.szyprowski@samsung.com>, "Kyungmin Park" <kyungmin.park@samsung.com>, "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se> Cc: Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Mauro Carvalho Chehab <mchehab@kernel.org>, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Subject: Re: [PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM Date: Mon, 14 Jan 2019 14:16:46 +0000 [thread overview] Message-ID: <f8f9e4f0-87fc-9f4f-37ea-39297acc8d31@arm.com> (raw) In-Reply-To: <20190111181731.11782-3-hch@lst.de> 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 <hch@lst.de> > --- > 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 <robin.murphy@arm.com> > - 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); > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-14 14:16 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20190111181841epcas3p2d7c0bf8f5c11a9863e22ec1b12da6e1b@epcas3p2.samsung.com> 2019-01-11 18:17 ` fix a layering violation in videobuf2 and improve dma_map_resource Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-11 18:17 ` [PATCH 1/3] dma-mapping: remove the default map_resource implementation Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-14 13:12 ` Robin Murphy 2019-01-14 13:12 ` Robin Murphy 2019-01-14 17:08 ` Christoph Hellwig 2019-01-14 17:08 ` Christoph Hellwig 2019-01-14 17:08 ` Christoph Hellwig 2019-01-11 18:17 ` [PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-14 14:16 ` Robin Murphy [this message] 2019-01-14 14:16 ` Robin Murphy 2019-01-11 18:17 ` [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-11 18:17 ` Christoph Hellwig 2019-01-11 19:54 ` Mauro Carvalho Chehab 2019-01-11 19:54 ` Mauro Carvalho Chehab 2019-01-11 19:54 ` Mauro Carvalho Chehab 2019-01-14 10:31 ` Christoph Hellwig 2019-01-14 10:31 ` Christoph Hellwig 2019-01-14 10:31 ` Christoph Hellwig 2019-01-14 11:04 ` Mauro Carvalho Chehab 2019-01-14 11:04 ` Mauro Carvalho Chehab 2019-01-14 11:04 ` Mauro Carvalho Chehab 2019-01-14 11:12 ` Christoph Hellwig 2019-01-14 11:12 ` Christoph Hellwig 2019-01-14 11:12 ` Christoph Hellwig 2019-01-14 12:42 ` Marek Szyprowski 2019-01-14 12:42 ` Marek Szyprowski 2019-01-14 12:42 ` Marek Szyprowski 2019-01-17 17:21 ` Christoph Hellwig 2019-01-17 17:21 ` Christoph Hellwig 2019-01-17 17:21 ` Christoph Hellwig 2019-01-18 9:41 ` Marek Szyprowski 2019-01-18 9:41 ` Marek Szyprowski 2019-01-18 9:41 ` Marek Szyprowski 2019-01-31 15:31 ` Christoph Hellwig 2019-01-31 15:31 ` Christoph Hellwig 2019-01-31 15:31 ` Christoph Hellwig 2019-01-14 11:43 ` fix a layering violation in videobuf2 and improve dma_map_resource Marek Szyprowski 2019-01-14 11:43 ` Marek Szyprowski 2019-01-14 11:43 ` Marek Szyprowski 2019-01-18 11:37 fix a layering violation in videobuf2 and improve dma_map_resource v2 Christoph Hellwig 2019-01-18 11:37 ` [PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM Christoph Hellwig 2019-01-18 11:37 ` Christoph Hellwig 2019-01-18 11:37 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=f8f9e4f0-87fc-9f4f-37ea-39297acc8d31@arm.com \ --to=robin.murphy@arm.com \ --cc=hch@lst.de \ --cc=iommu@lists.linux-foundation.org \ --cc=kyungmin.park@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=m.szyprowski@samsung.com \ --cc=mchehab@kernel.org \ --cc=niklas.soderlund+renesas@ragnatech.se \ --cc=pawel@osciak.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.