lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 27 Sep 2014 10:30:34 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Akinobu Mita <akinobu.mita@...il.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
CC:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Don Dutile <ddutile@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	x86@...nel.org, iommu@...ts.linux-foundation.org
Subject: Re: [PATCH v3 0/5] enhance DMA CMA on x86

On 04/15/2014 09:08 AM, Akinobu Mita wrote:
> This patch set enhances the DMA Contiguous Memory Allocator on x86.
> 
> Currently the DMA CMA is only supported with pci-nommu dma_map_ops
> and furthermore it can't be enabled on x86_64.  But I would like to
> allocate big contiguous memory with dma_alloc_coherent() and tell it
> to the device that requires it, regardless of which dma mapping
> implementation is actually used in the system.
> 
> So this makes it work with swiotlb and intel-iommu dma_map_ops, too.
> And this also extends "cma=" kernel parameter to specify placement
> constraint by the physical address range of memory allocations.  For
> example, CMA allocates memory below 4GB by "cma=64M@...G", it is
> required for the devices only supporting 32-bit addressing on 64-bit
> systems without iommu.
> 
> * Changes from v2
> - Rebased on current Linus tree
> - Add Acked-by line
> - Fix gfp flags check for __GFP_ATOMIC, reported by Marek Szyprowski
> - Avoid CMA area on highmem with cma= option, reported by Marek Szyprowski
> 
> * Changes from v1
> - fix dma_alloc_coherent() with __GFP_ZERO
> - add placement specifier for "cma=" kernel parameter
> 
> Akinobu Mita (5):
>   x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled
>   x86: enable DMA CMA with swiotlb
>   intel-iommu: integrate DMA CMA
>   memblock: introduce memblock_alloc_range()
>   cma: add placement specifier for "cma=" kernel parameter

This patchset breaks every x86 iommu configuration when CONFIG_DMA_CMA is
on, which is the base configuration for Ubuntu x86 and amd64 distro kernels.

Granted, the patchset leveraged existing code from the nommu configuration,
but that base (ie., calling dma_alloc_from_contiguous() in
dma_generic_alloc_config()) was an ill-conceived test configuration designed
to allow ARM developers to validate the CMA allocator on x86 boxen and
KVM guests, not as a general-purpose replacement for the existing page
allocator. The test code should have had a separate CONFIG_ knob.

What this patchset does is restrict all iommu configurations which can
map all of system memory to one _very_ small physical region, thus disabling
the whole point of an iommu.

Now I know why my GPU is causing paging to disk! And why my RAID controller
stalls for ages when I do a git log at the same time as a kernel build!

And the apparent goal of this patchset is to enable DMA allocation below
4GB, which is already supported in the existing page allocator with the
GFP_DMA32 flag?!

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ