linux-kernel - Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator

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]

Message-Id: <201107062223.01940.arnd@arndb.de>
Date:	Wed, 6 Jul 2011 22:23:01 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linaro-mm-sig@...ts.linaro.org
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	"'Daniel Walker'" <dwalker@...eaurora.org>,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	linux-media@...r.kernel.org, "'Jonathan Corbet'" <corbet@....net>,
	"'Mel Gorman'" <mel@....ul.ie>,
	"'Chunsang Jeong'" <chunsang.jeong@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"'Michal Nazarewicz'" <mina86@...a86.com>,
	"'Jesse Barker'" <jesse.barker@...aro.org>,
	"'Kyungmin Park'" <kyungmin.park@...sung.com>,
	"'KAMEZAWA Hiroyuki'" <kamezawa.hiroyu@...fujitsu.com>,
	"'Andrew Morton'" <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-arm-kernel@...ts.infradead.org,
	"'Ankita Garg'" <ankita@...ibm.com>
Subject: Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator

On Wednesday 06 July 2011 21:10:07 Nicolas Pitre wrote:
> If you get a highmem page, because the cache is VIPT, that page might 
> still be cached even if it wasn't mapped.  With a VIVT cache we must 
> flush the cache whenever a highmem page is unmapped.  There is no such 
> restriction with VIPT i.e. ARMv6 and above.  Therefore to make sure the 
> highmem page you get doesn't have cache lines associated to it, you must 
> first map it cacheable, then perform cache invalidation on it, and 
> eventually remap it as non-cacheable.  This is necessary because there 
> is no way to perform cache maintenance on L1 cache using physical 
> addresses unfortunately.  See commit 7e5a69e83b for an example of what 
> this entails (fortunately commit 3e4d3af501 made things much easier and 
> therefore commit 39af22a79 greatly simplified things).

Ok, thanks for the explanation. This definitely makes the highmem approach
much harder to get right, and slower. Let's hope then that Marek's approach
of using small pages for the contiguous memory region and changing their
attributes on the fly works out better than this.

	Arnd
--
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/