Re: [ 00/13] 3.0.99-stable review

[Guenter Roeck <linux@roeck-us.net>]

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.
>
>
>