All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.