linux-kernel - Re: [Xen-devel] [PATCH tip/x86/mm] x86_32: calculate additional memory needed by the fixmap

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] [day] [month] [year] [list]

Date:	Wed, 20 Jul 2011 09:09:04 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Ian Jackson <Ian.Jackson@...citrix.com>
Cc:	stefano.stabellini@...citrix.com, xen-devel@...ts.xensource.com,
	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...e.hu,
	hpa@...ux.intel.com, yinghai@...nel.org
Subject: Re: [Xen-devel] [PATCH tip/x86/mm] x86_32: calculate additional
 memory needed by the fixmap

On Mon, Jul 18, 2011 at 05:29:21PM +0100, Ian Jackson wrote:
> stefano.stabellini@...citrix.com writes ("[Xen-devel] [PATCH tip/x86/mm] x86_32: calculate additional memory needed by the fixmap"):
> > Unfortunately this code is rather complex and depends on the behaviour
> > of other functions but I hope to have covered all the corner cases.
> 
> I'm sorry to say that think this is really the wrong approach.
> I agree that *some* change needs to be made, as this is currently a
> serious regression in tip/x86/mm.

tip/x86/mm should boot with this patch, right?

> 
> But the correct change is in fact to undo the reversion of
>   "x86,xen: introduce x86_init.mapping.pagetable_reserve"
> That was a hook with a reasonable and defined interface.
> 
> What we are having instead, now, is a fragile piece of code that tries
> to second-guess the complex config- and hardware-dependent
> memory-allocation behaviour of the rest of the startup code.  This is
> a recipe for making things break.

Stefano did an excellent job at doing an archaeological excavation
and finding all the little pieces and bringing them up to surface
via this function. We have now the full accounting of the early
bootup code and its page table creation. And based on that we can
tighten the dance between pgt_end/pgt_begin/pgt_top to WARN much
sooner - and I hope make the code more simpler.

Sure there are some bugs that we won't find until more folks start
testing it - I've only found this one b/c of playing with a bigger
set of .config variants. But that is part of the 3.1-rcX cycle - to
find them and fix them. Or if we cannot fix them, then revert this
whole patchset and think then some more - maybe at the Linux Plumbers
Conference or the Linux Kernel mini-summits.
--
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/