Re: [ 00/13] 3.0.99-stable review

[Guenter Roeck]

On Thu, Oct 03, 2013 at 07:35:35AM -0600, Khalid Aziz wrote:
> On 10/03/2013 06: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.
> >
> >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?
> 
> Thanks for tracking this down. I had not tried a configuration with
> CONFIG_HUGETLB_PAGE not set. In my config, I was getting many
> multiple definition errors for bunch of other defines from
> linux/hugetlb.h. I will look at my config again but chances are I
> had something else screwed up in my build since you did not see
> those errors. Did you compile with CONFIG_HUGETLB_PAGE set after
> including linux/hugetlb.h? If you did, including linux/hugetlb.h
> instead of importing just the definition of PageHuge in mm/swap.c
> would be the right thing to do.
> 

For my part, what I do is to compile lots of standard configurations.
I don't look into details. If you are interested, go to
http://server.roeck-us.net:8010/builders, click on any of the many
failed builds for 3.0 or 3.4, then click on "stdio" on the build page.
You'll see the build log, which also lists the names of the failed
configurations.

An easy start might be x86_64:allnoconfig or i386:allnoconfig,
both of which fail.

Thanks,
Guenter

> --
> Khalid
> 
> >
> >     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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/