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-next>] [day] [month] [year] [list]
Message-ID: <20160607125911.GA4279@tiger>
Date:	Tue, 7 Jun 2016 20:59:13 +0800
From:	Shawn Guo <shawnguo@...nel.org>
To:	linux-kernel@...r.kernel.org, inux-arm-kernel@...ts.infradead.org
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Arnd Bergmann <arnd@...db.de>,
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Laura Abbott <lauraa@...eaurora.org>,
	Minchan Kim <minchan@...nel.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Shawn Guo <shawnguo@...nel.org>
Subject: CMA region absolutely for a particular device?

Hi,

I'm using a separate CMA region than the system default one for
a particular device to avoid fragmentation.  It does help.  But under
certain circumstance (memory shortage), it seems some of the pages in
the region will be used by system.  The really bad thing is that when
a CMA allocation tries to move these occupied pages around, it just
fails to do so with messages like "alloc_contig_range: ... PFNs busy".
These pages thus become holes in a contiguous block and prevent the
allocation from succeeding.

Is it possible to make a CMA absolutely for a particular device, and
even system movable pages cannot use the memory?  I can reserve a memory
region from kernel and manage it with some custom and private interface
for that particular device.  But obviously, the standard dma-mapping API
and established underneath CMA infrastructural is more desirable to use,
right?

This is an arm64 device running on 4.1 kernel.  Any comments or
suggestions will be appreciated.  Thanks.

Shawn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ