linux-kernel - Re: [ 00/13] 3.0.99-stable review

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <524D711C.30605@roeck-us.net>
Date:	Thu, 03 Oct 2013 06:29:00 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Christoph Biedl <linux-kernel.bfrz@...chmal.in-ulm.de>,
	stable@...r.kernel.org
CC:	linux-kernel@...r.kernel.org, Khalid Aziz <khalid.aziz@...cle.com>
Subject: Re: [ 00/13] 3.0.99-stable review

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