All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Will Deacon <will@kernel.org>
Cc: Shawn Anastasio <shawn@anastas.io>,
	Michael Ellerman <mpe@ellerman.id.au>,
	linuxppc-dev@lists.ozlabs.org,
	Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] dma-mapping: fix page attributes for dma_mmap_*
Date: Fri, 2 Aug 2019 10:14:41 +0200	[thread overview]
Message-ID: <20190802081441.GA9725@lst.de> (raw)
In-Reply-To: <20190801164411.kmsl4japtfkgvzxe@willie-the-truck>

On Thu, Aug 01, 2019 at 05:44:12PM +0100, Will Deacon wrote:
> > > Although arch_dma_mmap_pgprot() is a bit of a misnomer now that it only
> > > gets involved in the non-coherent case.
> > 
> > A better name is welcome.
> 
> How about arch_dma_noncoherent_mmap_pgprot() ? Too long?

Sounds a little long yes.  And doesn't fix the additional problem that
we don't just it for mmap but also for the in-kernel remapping these
days.

> > But my worry is how this interacts with architectures that have an
> > uncached segment (mips, nios2, microblaze, extensa) where we'd have
> > the kernel access DMA_ATTR_WRITE_COMBINE mappigns using the uncached
> > segment, and userspace mmaps using pgprot_writecombine, which could
> > lead to aliasing issues.  But then again mips already supports
> > DMA_ATTR_WRITE_COMBINE, so this must be ok somehow.  I guess I'll
> > need to field that question to the relevant parties.
> 
> Or it's always been busted and happens to work out in practice...

I've sent a ping to the mips folks.  While we'are at it:  arm64
and arm32 (optionally) map dma coherent allocations as write combine.
I suspect this hasn't always just been busted but intentional (of course!),
but is there any chance to get a quote from the arm architecture spec
on why this is fine as it looks rather confusion?

Also if we assume mips is buggy DMA_ATTR_WRITE_COMBINE really just seems
to be there for old arm platforms, which makes the scope pretty limited.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Will Deacon <will@kernel.org>
Cc: Shawn Anastasio <shawn@anastas.io>,
	linuxppc-dev@lists.ozlabs.org,
	Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] dma-mapping: fix page attributes for dma_mmap_*
Date: Fri, 2 Aug 2019 10:14:41 +0200	[thread overview]
Message-ID: <20190802081441.GA9725@lst.de> (raw)
In-Reply-To: <20190801164411.kmsl4japtfkgvzxe@willie-the-truck>

On Thu, Aug 01, 2019 at 05:44:12PM +0100, Will Deacon wrote:
> > > Although arch_dma_mmap_pgprot() is a bit of a misnomer now that it only
> > > gets involved in the non-coherent case.
> > 
> > A better name is welcome.
> 
> How about arch_dma_noncoherent_mmap_pgprot() ? Too long?

Sounds a little long yes.  And doesn't fix the additional problem that
we don't just it for mmap but also for the in-kernel remapping these
days.

> > But my worry is how this interacts with architectures that have an
> > uncached segment (mips, nios2, microblaze, extensa) where we'd have
> > the kernel access DMA_ATTR_WRITE_COMBINE mappigns using the uncached
> > segment, and userspace mmaps using pgprot_writecombine, which could
> > lead to aliasing issues.  But then again mips already supports
> > DMA_ATTR_WRITE_COMBINE, so this must be ok somehow.  I guess I'll
> > need to field that question to the relevant parties.
> 
> Or it's always been busted and happens to work out in practice...

I've sent a ping to the mips folks.  While we'are at it:  arm64
and arm32 (optionally) map dma coherent allocations as write combine.
I suspect this hasn't always just been busted but intentional (of course!),
but is there any chance to get a quote from the arm architecture spec
on why this is fine as it looks rather confusion?

Also if we assume mips is buggy DMA_ATTR_WRITE_COMBINE really just seems
to be there for old arm platforms, which makes the scope pretty limited.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Will Deacon <will@kernel.org>
Cc: Shawn Anastasio <shawn@anastas.io>,
	Michael Ellerman <mpe@ellerman.id.au>,
	linuxppc-dev@lists.ozlabs.org,
	Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] dma-mapping: fix page attributes for dma_mmap_*
Date: Fri, 2 Aug 2019 10:14:41 +0200	[thread overview]
Message-ID: <20190802081441.GA9725@lst.de> (raw)
In-Reply-To: <20190801164411.kmsl4japtfkgvzxe@willie-the-truck>

On Thu, Aug 01, 2019 at 05:44:12PM +0100, Will Deacon wrote:
> > > Although arch_dma_mmap_pgprot() is a bit of a misnomer now that it only
> > > gets involved in the non-coherent case.
> > 
> > A better name is welcome.
> 
> How about arch_dma_noncoherent_mmap_pgprot() ? Too long?

Sounds a little long yes.  And doesn't fix the additional problem that
we don't just it for mmap but also for the in-kernel remapping these
days.

> > But my worry is how this interacts with architectures that have an
> > uncached segment (mips, nios2, microblaze, extensa) where we'd have
> > the kernel access DMA_ATTR_WRITE_COMBINE mappigns using the uncached
> > segment, and userspace mmaps using pgprot_writecombine, which could
> > lead to aliasing issues.  But then again mips already supports
> > DMA_ATTR_WRITE_COMBINE, so this must be ok somehow.  I guess I'll
> > need to field that question to the relevant parties.
> 
> Or it's always been busted and happens to work out in practice...

I've sent a ping to the mips folks.  While we'are at it:  arm64
and arm32 (optionally) map dma coherent allocations as write combine.
I suspect this hasn't always just been busted but intentional (of course!),
but is there any chance to get a quote from the arm architecture spec
on why this is fine as it looks rather confusion?

Also if we assume mips is buggy DMA_ATTR_WRITE_COMBINE really just seems
to be there for old arm platforms, which makes the scope pretty limited.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Will Deacon <will@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	iommu@lists.linux-foundation.org,
	Shawn Anastasio <shawn@anastas.io>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-mapping: fix page attributes for dma_mmap_*
Date: Fri, 2 Aug 2019 10:14:41 +0200	[thread overview]
Message-ID: <20190802081441.GA9725@lst.de> (raw)
In-Reply-To: <20190801164411.kmsl4japtfkgvzxe@willie-the-truck>

On Thu, Aug 01, 2019 at 05:44:12PM +0100, Will Deacon wrote:
> > > Although arch_dma_mmap_pgprot() is a bit of a misnomer now that it only
> > > gets involved in the non-coherent case.
> > 
> > A better name is welcome.
> 
> How about arch_dma_noncoherent_mmap_pgprot() ? Too long?

Sounds a little long yes.  And doesn't fix the additional problem that
we don't just it for mmap but also for the in-kernel remapping these
days.

> > But my worry is how this interacts with architectures that have an
> > uncached segment (mips, nios2, microblaze, extensa) where we'd have
> > the kernel access DMA_ATTR_WRITE_COMBINE mappigns using the uncached
> > segment, and userspace mmaps using pgprot_writecombine, which could
> > lead to aliasing issues.  But then again mips already supports
> > DMA_ATTR_WRITE_COMBINE, so this must be ok somehow.  I guess I'll
> > need to field that question to the relevant parties.
> 
> Or it's always been busted and happens to work out in practice...

I've sent a ping to the mips folks.  While we'are at it:  arm64
and arm32 (optionally) map dma coherent allocations as write combine.
I suspect this hasn't always just been busted but intentional (of course!),
but is there any chance to get a quote from the arm architecture spec
on why this is fine as it looks rather confusion?

Also if we assume mips is buggy DMA_ATTR_WRITE_COMBINE really just seems
to be there for old arm platforms, which makes the scope pretty limited.

  reply	other threads:[~2019-08-02  8:14 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 14:21 fix default dma_mmap_* pgprot Christoph Hellwig
2019-08-01 14:21 ` Christoph Hellwig
2019-08-01 14:21 ` Christoph Hellwig
2019-08-01 14:21 ` Christoph Hellwig
2019-08-01 14:21 ` [PATCH] dma-mapping: fix page attributes for dma_mmap_* Christoph Hellwig
2019-08-01 14:21   ` Christoph Hellwig
2019-08-01 14:21   ` Christoph Hellwig
2019-08-01 14:21   ` Christoph Hellwig
2019-08-01 16:23   ` Will Deacon
2019-08-01 16:23     ` Will Deacon
2019-08-01 16:23     ` Will Deacon
2019-08-01 16:23     ` Will Deacon
2019-08-01 16:34     ` Christoph Hellwig
2019-08-01 16:34       ` Christoph Hellwig
2019-08-01 16:34       ` Christoph Hellwig
2019-08-01 16:34       ` Christoph Hellwig
2019-08-01 16:44       ` Will Deacon
2019-08-01 16:44         ` Will Deacon
2019-08-01 16:44         ` Will Deacon
2019-08-01 16:44         ` Will Deacon
2019-08-02  8:14         ` Christoph Hellwig [this message]
2019-08-02  8:14           ` Christoph Hellwig
2019-08-02  8:14           ` Christoph Hellwig
2019-08-02  8:14           ` Christoph Hellwig
2019-08-02 10:38           ` Will Deacon
2019-08-02 10:38             ` Will Deacon
2019-08-02 10:38             ` Will Deacon
2019-08-02 10:38             ` Will Deacon
2019-08-03  6:48             ` Christoph Hellwig
2019-08-03  6:48               ` Christoph Hellwig
2019-08-03  6:48               ` Christoph Hellwig
2019-08-03  6:48               ` Christoph Hellwig
2019-08-06 16:08               ` Will Deacon
2019-08-06 16:08                 ` Will Deacon
2019-08-06 16:08                 ` Will Deacon
2019-08-06 16:08                 ` Will Deacon
2019-08-06 16:45                 ` Russell King - ARM Linux admin
2019-08-06 16:45                   ` Russell King - ARM Linux admin
2019-08-06 16:45                   ` Russell King - ARM Linux admin
2019-08-06 16:45                   ` Russell King - ARM Linux admin
2019-08-06 16:48                   ` Russell King - ARM Linux admin
2019-08-06 16:48                     ` Russell King - ARM Linux admin
2019-08-06 16:48                     ` Russell King - ARM Linux admin
2019-08-06 16:48                     ` Russell King - ARM Linux admin
2019-08-07  6:14                   ` Christoph Hellwig
2019-08-07  6:14                     ` Christoph Hellwig
2019-08-07  6:14                     ` Christoph Hellwig
2019-08-07  6:14                     ` 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=20190802081441.GA9725@lst.de \
    --to=hch@lst.de \
    --cc=catalin.marinas@arm.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=robin.murphy@arm.com \
    --cc=shawn@anastas.io \
    --cc=will@kernel.org \
    /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.