linux-kernel - Re: [tip:core/urgent] memblock: Fix alloc failure due to dumb underflow protection in memblock_find_in_range

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:	Tue, 24 Jan 2012 22:58:41 -0500
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	benh@...nel.crashing.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, tj@...nel.org, tglx@...utronix.de,
	mingo@...e.hu
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:core/urgent] memblock: Fix alloc failure due to dumb
 underflow protection in memblock_find_in_range_node ()

On Tue, Jan 24, 2012 at 09:51:32AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 16, 2012 at 01:03:50AM -0800, tip-bot for Tejun Heo wrote:
> > Commit-ID:  5d53cb27d849c899136c048ec84c940ac449494b
> > Gitweb:     http://git.kernel.org/tip/5d53cb27d849c899136c048ec84c940ac449494b
> > Author:     Tejun Heo <tj@...nel.org>
> > AuthorDate: Fri, 13 Jan 2012 10:14:12 -0800
> > Committer:  Ingo Molnar <mingo@...e.hu>
> > CommitDate: Mon, 16 Jan 2012 08:38:06 +0100
> > 
> > memblock: Fix alloc failure due to dumb underflow protection in memblock_find_in_range_node()
> > 
> > 7bd0b0f0da ("memblock: Reimplement memblock allocation using
> > reverse free area iterator") implemented a simple top-down
> > allocator using a reverse memblock iterator.  To avoid underflow
> > in the allocator loop, it simply raised the lower boundary to
> > the requested size under the assumption that requested size
> > would be far smaller than available memblocks.
> > 
> > This causes early page table allocation failure under certain
> > configurations in Xen.  Fix it by checking for underflow directly
> > instead of bumping up lower bound.
> 
> Well, it fixes my 4GB problem, but when I try to boot a 2GB (1GB of that
> is for balloon usage) guest (i386 only) I get a new failure:
> 
> > more /mnt/lab/bootstrap-i386/test.xm 
> extra="console=hvc0 debug earlyprintk=xen memblock=debug"
> kernel="/mnt/lab/bootstrap-i386/vmlinuz"
> ramdisk="/mnt/lab/bootstrap-i386/initramfs.cpio.gz"
> memory=1024
> maxmem=2048
> vcpus=2
> name="bootstrap-i386"
> on_crash="preserve"
> vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
> vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
> disk=['phy:/dev/vg_guests/bootstrap-i386,xvda,w']
> 
> So this is v3.3-rc1 + this patch by itself. Any thoughts of what else
> might be amiss?

My apologies, I had been building new kernels everyday and the /lib/modules
was getting filled with v3.3-rc1-000XX making the initramfs bigger and bigger
until well - it no longer could fit in memory. And I added this specific patch
in my testing queue which triggered another build and caused the initramfs to
grow just too big:

> (early) [    0.000000] initrd too large to handle, disabling initrd

while the previous initramfs were under the size constraint.

So, the patch is good, I've retested it and fixed my AutoMaticBuildThingy
to clean up /lib/modules before the built and sorry for the scare! 

Please apply this patch to 3.3-rc1 at your earliest convience! Thanks!
--
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/