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: <4CB6107F.4080908@goop.org>
Date:	Wed, 13 Oct 2010 13:03:11 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
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 11:20 AM, H. Peter Anvin wrote:
> 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.

Me too.  I'd like to fix the Xen code to handle any pages.

> 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.

The allocation is done in find_early_table_space() in x86/mm/init.c, so
the allocation call itself can't be easily replaced, but I suppose some
of the parameters could be global and tweaked by Xen code, but that's
pretty ugly.

> 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?

I'm looking at ways of avoiding the dependency on bottom-up allocation
at the moment.  It looks like it's OK if I can assume that the pagetable
is being allocated out of pages in the range
e820_table_start-e820_table_end (though one hopes those will get renamed
to something a bit more meaningful).

I should know how its going to turn out later today.

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