linux-kernel - Re: [PATCH 0/4] memblock related fixes for -tip

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: <4CB5F86C.9030900@zytor.com>
Date:	Wed, 13 Oct 2010 11:20:28 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH 0/4] memblock related fixes for -tip

On 10/13/2010 09:31 AM, Jeremy Fitzhardinge wrote:
>>
>> use ARCH_FIND_MEMBLOCK_AREA to select from them.
> 
> Thanks, that fixes the problem.  I would ideally like to make the the
> Xen code independent of the page allocation ordering, but it looks like
> it will be very tricky since we effectively make use of the pagetable as
> a way of storing one bit of information about each page before there's a
> struct page in place.
> 
> So this patch looks good to me (but there's no need to make it a
> separate config option).
> 

There isn't per se, but I have repeatedly expressed unhappiness about
x86 having a completely different allocation policy -- worse, bottom-up
is the absolutely worst possible allocation policy since low-address
memory is a precious resource for all kinds of odd requirements
(trampoline pages, ZONE_DMA, ZONE_DMA32 and so on.)

Furthermore, I really, really disapprove of interfaces which carry
hidden semantics, such as allocation order.

I have repeatedly asked that we do *not* do this on x86 if we're going
to go to a memblock-everywhere configuration.

Now, if Xen needs it, there are few options that I can see in the short
term, neither of which makes me happy -- I would appreciate

a) Add an explicit interface to allocate bottoms-up, and have Xen use it
because it needs it.  This is appropriate if (and only if) the
allocations in Xen aren't underneath a bunch of extra layers.

b) Add it as a config option and make Xen select it (or depend on it).
Unfortunately this probably would mean using this option on any
paravirtualized kernel too, which would effectively mean Xen is
"infecting" the entire rest of the x86 architecture with a pessimal
allocation policy, which is extremely unfortunate.

c) Just accept it for now with the intent of getting rid of it as soon
as possible.  I'd be fine pushing this for 2.6.37, but I'd like to get a
reasonably firm commitment try to come up with something better within
the next kernel cycle.

Opinions?

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