linux-kernel - Re: HOLES_IN

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:	Thu, 05 Feb 2009 15:44:03 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	heiko.carstens@...ibm.com
Cc:	mel@....ul.ie, kamezawa.hiroyu@...fujitsu.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	sparclinux@...r.kernel.org
Subject: Re: HOLES_IN_ZONE...

From: Heiko Carstens <heiko.carstens@...ibm.com>
Date: Thu, 5 Feb 2009 09:00:16 +0100

> On Wed, 04 Feb 2009 22:26:51 -0800 (PST)
> David Miller <davem@...emloft.net> wrote:
> 
> > Later this HOLES_IN_ZONE requirement was removed on s390 by commit:
> > 
> > commit 9f4b0ba81f158df459fa2cfc98ab1475c090f29c
> > Author: Heiko Carstens <heiko.carstens@...ibm.com>
> > Date:   Sat Jan 26 14:11:02 2008 +0100
> > 
> >     [S390] Get rid of HOLES_IN_ZONE requirement.
> 
> This just made sure that all zones start on a MAX_ORDER boundary and
> just leaves memory that doesn't fit unused. So the requirement for
> HOLES_IN_ZONE went away.
> 
> Later I reduced MAX_ORDER to 9 on s390, so we don't leave large
> portions of memory unused.

Isn't is easier to just make sure your vmemmap mappings extend to such
boundaries, whether they contain available memory or not?

That's the only requirement you have to satisfy to avoid having to
specify HOLES_IN_ZONE.  You don't have to have memory there, just
some vmmemmap page structs have to be mapped at those indices.

And then you won't need waste memory with these MAX_ORDER boundary
adjustments.

Really, I think IA64 should do this too (it's the only remaining
HOLES_IN_ZONE setting arch), then we can just delete this whole thing
completely.
--
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/