On 10/03/2013 05:47 AM, Christoph Biedl wrote:
Guenter Roeck wrote...
On 10/02/2013 09:04 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.0.99 release.
Heads up: I am getting lots of build failures in 3.0 and 3.4 builds.
mm/built-in.o: In function `__put_compound_page':
slab.c:(.text+0xaa3c): undefined reference to `PageHuge'
mm/built-in.o: In function `put_compound_page':
slab.c:(.text+0xaab0): undefined reference to `PageHuge'
mm/built-in.o: In function `__get_page_tail':
slab.c:(.text+0xb178): undefined reference to `PageHuge'
make: *** [.tmp_vmlinux1] Error 1
This is obviously due to
| [ 11/13] mm: fix aio performance regression for database caused by THP
and happens if CONFIG_HUGETLB_PAGE is not set.
Thanks a lot for tracking this down.
Final build result is
total: 98 pass: 15 skipped: 16 fail: 67
for 3.0, which is obviously less than perfect.
All qemu tests failed as well, or rather the qemu images failed to build.
Guenter
Looking closer, upstream commit 7cb2ef56 included linux/hugetlb.h
while the backport for 3.0 just defines PageHuge. Reverting that like
in the patch below causes the build to complete, and the resulting
kernel shows no anomalies here.
However did that backport, why was it done that way? Or did I miss an
important point?
Christoph
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -31,6 +31,7 @@
#include <linux/backing-dev.h>
#include <linux/memcontrol.h>
#include <linux/gfp.h>
+#include <linux/hugetlb.h>
#include "internal.h"
@@ -41,8 +42,6 @@
static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs);
static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs);
-int PageHuge(struct page *page);
-
/*
* This path almost never happens for VM activity - pages are normally
* freed via pagevecs. But it gets used by networking.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html