Fix error check in memblock that prevented boot on various Dells (rhbz 811225)

kernel.spec

@@ -54,7 +54,7 @@ Summary: The Linux kernel
 # For non-released -rc kernels, this will be appended after the rcX and
 # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
 #
-%global baserelease 5
+%global baserelease 6
 %global fedora_build %{baserelease}
 
 # base_sublevel is the kernel version we're starting with and patching
@@ -814,6 +814,9 @@ Patch22007: macvtap-zerocopy-validate-vector-length.patch
 Patch22008: fcaps-clear-the-same-personality-flags-as-suid-when-.patch
 Patch22009: security-fix-compile-error-in-commoncap.c.patch
 
+#rhbz 811225
+Patch22010: memblock-memblock-should-be-able-to-handle-zero-leng.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -1519,6 +1522,9 @@ ApplyPatch macvtap-zerocopy-validate-vector-length.patch
 ApplyPatch fcaps-clear-the-same-personality-flags-as-suid-when-.patch
 ApplyPatch security-fix-compile-error-in-commoncap.c.patch
 
+#rhbz 811225
+ApplyPatch memblock-memblock-should-be-able-to-handle-zero-leng.patch
+
 # END OF PATCH APPLICATIONS
 
 %endif
@@ -2257,6 +2263,9 @@ fi
 # and build.
 
 %changelog
+* Sat Apr 21 2012 Josh Boyer <jwboyer@redhat.com> - 3.3.2-6
+- Fix error check in memblock that prevented boot on various Dells (rhbz 811225)
+
 * Fri Apr 20 2012 Josh Boyer <jwboyer@redhat.com>
 - CVE-2012-2123 fcaps: clear the same personality flags as suid when fcaps
   are used (rhbz 814523 806722)

memblock-memblock-should-be-able-to-handle-zero-leng.patch

@@ -0,0 +1,63 @@
+From b3dc627cabb33fc95f93da78457770c1b2a364d2 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Fri, 20 Apr 2012 08:31:34 -0700
+Subject: [PATCH] memblock: memblock should be able to handle zero length
+ operations
+
+Commit 24aa07882b ("memblock, x86: Replace memblock_x86_reserve/
+free_range() with generic ones") replaced x86 specific memblock
+operations with the generic ones; unfortunately, it lost zero length
+operation handling in the process making the kernel panic if somebody
+tries to reserve zero length area.
+
+There isn't much to be gained by being cranky to zero length operations
+and panicking is almost the worst response.  Drop the BUG_ON() in
+memblock_reserve() and update memblock_add_region/isolate_range() so
+that all zero length operations are handled as noops.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Cc: stable@vger.kernel.org
+Reported-by: Valere Monseur <valere.monseur@ymail.com>
+Bisected-by: Joseph Freeman <jfree143dev@gmail.com>
+Tested-by: Joseph Freeman <jfree143dev@gmail.com>
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43098
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ mm/memblock.c |    7 ++++++-
+ 1 files changed, 6 insertions(+), 1 deletions(-)
+
+diff --git a/mm/memblock.c b/mm/memblock.c
+index 99f2855..a44eab3 100644
+--- a/mm/memblock.c
++++ b/mm/memblock.c
+@@ -330,6 +330,9 @@ static int __init_memblock memblock_add_region(struct memblock_type *type,
+ 	phys_addr_t end = base + memblock_cap_size(base, &size);
+ 	int i, nr_new;
+ 
++	if (!size)
++		return 0;
++
+ 	/* special case for empty array */
+ 	if (type->regions[0].size == 0) {
+ 		WARN_ON(type->cnt != 1 || type->total_size);
+@@ -430,6 +433,9 @@ static int __init_memblock memblock_isolate_range(struct memblock_type *type,
+ 
+ 	*start_rgn = *end_rgn = 0;
+ 
++	if (!size)
++		return 0;
++
+ 	/* we'll create at most two more regions */
+ 	while (type->cnt + 2 > type->max)
+ 		if (memblock_double_array(type) < 0)
+@@ -514,7 +520,6 @@ int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
+ 		     (unsigned long long)base,
+ 		     (unsigned long long)base + size,
+ 		     (void *)_RET_IP_);
+-	BUG_ON(0 == size);
+ 
+ 	return memblock_add_region(_rgn, base, size, MAX_NUMNODES);
+ }
+-- 
+1.7.7.6
+