For security reasons we already returned zeroed memory from
dma_alloc_coherent on most common platforms, but some implementation
missed out. Make sure we provide a consistent behavior.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists
We now always return zeroed memory from dma_alloc_coherent. Note that
simply passing GFP_ZERO to dma_alloc_coherent wasn't always doing the
right thing to start with given that various allocators are not backed
by the page allocator and thus would ignore GFP_ZERO.
Signed-off-by: Christoph Hellwig
If we want to map memory from the DMA allocator to userspace it must be
zeroed at allocation time to prevent stale data leaks. We already do
this on most common architectures, but some architectures don't do this
yet, fix them up, either by passing GFP_ZERO when we use the normal page
allocator o
Hi Christoph,
On Fri, Dec 14, 2018 at 9:26 AM Christoph Hellwig wrote:
> If we want to map memory from the DMA allocator to userspace it must be
> zeroed at allocation time to prevent stale data leaks. We already do
> this on most common architectures, but some architectures don't do this
> yet
On Fri, Dec 14, 2018 at 10:54 AM Geert Uytterhoeven
wrote:
> On Fri, Dec 14, 2018 at 9:26 AM Christoph Hellwig wrote:
> > If we want to map memory from the DMA allocator to userspace it must be
> > zeroed at allocation time to prevent stale data leaks. We already do
> > this on most common arch
On Thu, Dec 13, 2018 at 9:19 PM Fabrizio Castro
wrote:
> Document RZ/G2E (R8A774C0) SoC bindings.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68
On Thu, Dec 13, 2018 at 9:22 PM Fabrizio Castro
wrote:
> Support RZ/G2E (a.k.a. R8A774C0) IPMMU.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k
On Fri, Dec 14, 2018 at 10:54:32AM +0100, Geert Uytterhoeven wrote:
> > - page = alloc_pages(flag, order);
> > + page = alloc_pages(flag | GFP_ZERO, order);
> > if (!page)
> > return NULL;
>
> There's second implementation below, which calls __get_free_pages() a
On 12 December 2018 at 3:15PM, Christoph Hellwig wrote:
> Thanks for bisecting. I've spent some time going over the conversion
> but can't really pinpoint it. I have three little patches that switch
> parts of the code to the generic version. This is on top of the
> last good commmit (977706f97
Use the generic dma allocator to get various quirks and support
for CMA allocations (if enabled) for free.
Signed-off-by: Christoph Hellwig
---
arch/nios2/mm/dma-mapping.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/nios2/mm/dma-mapping.c b/arch/ni
On Fri, Dec 14, 2018 at 12:12:00PM +, Eugeniy Paltsev wrote:
> Hi Christoph,
>
> do you have any public git repository with all your dma changes?
Most of the tree show up in my misc.git repo for testing.
This series is here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dm
Hi Christoph,
On Fri, Dec 14, 2018 at 12:47 PM Christoph Hellwig wrote:
>
> On Fri, Dec 14, 2018 at 10:54:32AM +0100, Geert Uytterhoeven wrote:
> > > - page = alloc_pages(flag, order);
> > > + page = alloc_pages(flag | GFP_ZERO, order);
> > > if (!page)
> > > r
Christoph Hellwig writes:
> On Sun, Dec 09, 2018 at 09:23:39PM +1100, Michael Ellerman wrote:
>> Christoph Hellwig writes:
>>
>> > Configure the dma settings at device setup time, and stop playing games
>> > with get_pci_dma_ops. This prepares for using the common dma_configure
>> > code later
And in various places this used GFP_ZERO instead of __GFP_ZERO,
so won't compile.
The fixed version is available here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-alloc-always-zero
___
iommu mailing list
iommu@lists.linux-founda
Hi Christoph,
On 2018-12-07 20:07, Christoph Hellwig wrote:
> Avoid expensive indirect calls in the fast path DMA mapping
> operations by directly calling the dma_direct_* ops if we are using
> the directly mapped DMA operations.
>
> Signed-off-by: Christoph Hellwig
This breaks direct DMA on ARM
On Fri, Dec 14, 2018 at 03:11:37PM +0100, Marek Szyprowski wrote:
> Hi Christoph,
>
> On 2018-12-07 20:07, Christoph Hellwig wrote:
> > Avoid expensive indirect calls in the fast path DMA mapping
> > operations by directly calling the dma_direct_* ops if we are using
> > the directly mapped DMA op
Hi Christoph,
On 2018-12-14 15:24, Christoph Hellwig wrote:
> On Fri, Dec 14, 2018 at 03:11:37PM +0100, Marek Szyprowski wrote:
>> Hi Christoph,
>>
>> On 2018-12-07 20:07, Christoph Hellwig wrote:
>>> Avoid expensive indirect calls in the fast path DMA mapping
>>> operations by directly calling th
Otherwise the direct mapping won't work at all given that a NULL
dev->dma_ops causes a fallback. Note that we already explicitly set
dev->dma_ops to dma_dummy_ops for dma-incapable devices, so this
fallback should not be needed anyway.
Fixes: 356da6d0cd ("dma-mapping: bypass indirect calls for dm
On 14/12/18 9:47 pm, Christoph Hellwig wrote:
On Fri, Dec 14, 2018 at 10:54:32AM +0100, Geert Uytterhoeven wrote:
- page = alloc_pages(flag, order);
+ page = alloc_pages(flag | GFP_ZERO, order);
if (!page)
return NULL;
There's second implementation below
Hi Christoph,
do you have any public git repository with all your dma changes?
I want to test them for ARC.
Thanks.
On Fri, 2018-12-14 at 09:25 +0100, Christoph Hellwig wrote:
> If we want to map memory from the DMA allocator to userspace it must be
> zeroed at allocation time to prevent stale
On Thu, Dec 13, 2018 at 08:22:44PM +, Fabrizio Castro wrote:
> Support RZ/G2E (a.k.a. R8A774C0) IPMMU.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Simon Horman
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundati
On Sat, Dec 15, 2018 at 12:29:11AM +1100, Michael Ellerman wrote:
> I think the problem is that we don't want to set iommu_bypass_supported
> unless cell_iommu_fixed_mapping_init() succeeds.
>
> Yep. This makes it work for me on cell on top of your v5.
Thanks, this looks good. I've folded it wit
On Fri, Dec 14, 2018 at 01:00:26PM +0100, Christian Zigotzky wrote:
> On 12 December 2018 at 3:15PM, Christoph Hellwig wrote:
> > Thanks for bisecting. I've spent some time going over the conversion
> > but can't really pinpoint it. I have three little patches that switch
> > parts of the code to
Hi Christoph,
I stumbled upon this one:
#define __get_dma_pages(gfp_mask, order) \
__get_free_pages((gfp_mask) | GFP_DMA, (order))
(include/linux/gfp.h)
Should it also have the __GFP_ZERO treatment?
Or maybe this is already done in your tree..
As for the sparc bits:
Acked-by: Sa
On Fri, Dec 14, 2018 at 07:10:56PM +0100, Sam Ravnborg wrote:
> Hi Christoph,
>
> I stumbled upon this one:
>
> #define __get_dma_pages(gfp_mask, order) \
> __get_free_pages((gfp_mask) | GFP_DMA, (order))
This isn't directly related to the dma mapping, but another place
that hide
On Fri, Dec 07, 2018 at 11:07:18AM -0800, Christoph Hellwig wrote:
> From: Robin Murphy
>
> Rather than checking the DMA attribute at each callsite, just pass it
> through for acpi_dma_configure() to handle directly. That can then deal
> with the relatively exceptional DEV_DMA_NOT_SUPPORTED case
Conventional spelling in subject is
PCI: vmd: Use dma_* APIs instead of direct method calls
On Fri, Dec 07, 2018 at 11:07:19AM -0800, Christoph Hellwig wrote:
> With the bypass support for the direct mapping we might not always have
> methods to call, so use the proper APIs instead. The only d
Looks good to me
Thanks Christoph
Acked-by: Jon Derrick
On Fri, 2018-12-14 at 15:17 -0600, Bjorn Helgaas wrote:
> Conventional spelling in subject is
>
> PCI: vmd: Use dma_* APIs instead of direct method calls
>
> On Fri, Dec 07, 2018 at 11:07:19AM -0800, Christoph Hellwig wrote:
> > With th
On Wed, 12 Dec 2018 09:21:43 +0100
Auger Eric wrote:
> Hi Jacob,
>
> On 9/21/18 12:06 AM, Jacob Pan wrote:
> > On Tue, 18 Sep 2018 16:24:51 +0200
> > Eric Auger wrote:
> >
> >> From: Jacob Pan
> >>
> >> Device faults detected by IOMMU can be reported outside IOMMU
> >> subsystem for further
On Sat, Dec 08, 2018 at 09:41:12AM -0800, Christoph Hellwig wrote:
> There is no good reason to have a double indirection for the sparc32
> dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops
> instance for the different IOMMU types.
>
Except maybe this:
scsi host0: esp
scsi h
30 matches
Mail list logo
