linux-kernel - Re: [PATCHv4 2/2] arm: Get rid of meminfo

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: <20140312140522.GI21483@n2100.arm.linux.org.uk>
Date:	Wed, 12 Mar 2014 14:05:22 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Grygorii Strashko <grygorii.strashko@...com>
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Andrew Lunn <andrew@...n.ch>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Grant Likely <grant.likely@...retlab.ca>, linux-mm@...ck.org,
	Daniel Walker <dwalker@...o99.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	David Brown <davidb@...eaurora.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Laura Abbott <lauraa@...eaurora.org>,
	Jason Cooper <jason@...edaemon.net>,
	linux-arm-msm@...r.kernel.org,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Ben Dooks <ben-linux@...ff.org>,
	linux-arm-kernel@...ts.infradead.org,
	Courtney Cavin <courtney.cavin@...ymobile.com>,
	Eric Miao <eric.y.miao@...il.com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	linux-kernel@...r.kernel.org,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCHv4 2/2] arm: Get rid of meminfo

On Wed, Mar 12, 2014 at 01:38:06PM +0000, Russell King - ARM Linux wrote:
> Try booting a machine with 2G of RAM with page offset set to 3GB and
> highmem enabled - it will fail as per the above.

BTW, simple way to test this on any ARM platform:

Build with PAGE_OFFSET=3GB and highmem enabled.  Pass vmalloc=1G on the
kernel command line to force maximal vmalloc region (which should push
lowmem down to the minimum of 32MB.)  The remainder will be highmem.

Now, with Laura's patch applied, some platforms do boot but the result
is rather odd:

vmalloc area is too big, limiting to 976MB

So, the vmalloc=1G has done the right thing here, but:

Memory: 507404K/523264K available (3839K kernel code, 230K rwdata, 1388K rodata, 211K init, 5266K bss, 15860K reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0522f34   (5228 kB)
      .init : 0xc0523000 - 0xc0557fc0   ( 212 kB)
      .data : 0xc0558000 - 0xc0591980   ( 231 kB)
       .bss : 0xc0591988 - 0xc0ab6220   (5267 kB)

something has overriden it, and we end up with no highmem.  Without
Laura's patch, it all behaves correctly:

vmalloc area is too big, limiting to 976MB
...
Memory: 507932K/523264K available (3839K kernel code, 230K rwdata, 1388K rodata, 211K init, 5266K bss, 15332K reserved, 490496K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc2800000 - 0xff000000   ( 968 MB)
    lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0522f34   (5228 kB)
      .init : 0xc0523000 - 0xc0557fc0   ( 212 kB)
      .data : 0xc0558000 - 0xc0591980   ( 231 kB)
       .bss : 0xc0591988 - 0xc0ab6260   (5267 kB)

So... the more I look at the boot results from last night's autobuild,
the more stuff appears to be broken with this meminfo removal.

Therefore, I have to wonder what kind of testing was done with these
patches - I suspect the test consisted of "does it boot" without looking
at any of the details about what memory was where.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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/