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: <20131003155620.GA30315@roeck-us.net>
Date:	Thu, 3 Oct 2013 08:56:20 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Khalid Aziz <khalid.aziz@...cle.com>
Cc:	Christoph Biedl <linux-kernel.bfrz@...chmal.in-ulm.de>,
	stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [ 00/13] 3.0.99-stable review

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/