linux-kernel - Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO

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, 29 Jun 2013 10:57:43 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Santosh Shilimkar <santosh.shilimkar@...com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	sparclinux@...r.kernel.org, Sam Ravnborg <sam@...nborg.org>,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

( Expanding cc list, original thread is at
  http://thread.gmane.org/gmane.linux.kernel/1518046 )

Hello,

On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more.  This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
> 
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.

Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....

Given that still about half of the archs aren't using memblock yet, I
think there are three options.

1. Converting all bootmem interface to use physaddr_t.  But that's
   what memblock is.

2. Introducing new interface.  Easier right now but the danger there
   is that it might end up duplicating most of alloc_bootmem()
   interface anyway and we'll have yet another variant of early mem
   allocator to enjoy.

3. Make all generic code use memblock interface instead of bootmem and
   implement memblock wrapper on archs which don't use memblock yet.
   We'll probably need to sort out different combinations of
   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
   the most future proof way.  While it adds new memblock interface
   built on top of bootmem, it would also allow removing the bootmem
   interface built on top of memblock - ie. nobootmem.c, which
   probably is what we should have done from the beginning.

What do you guys think?

Thanks.

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