Bug 454228 – sys-kernel/hardened-sources-3.2.37-r2 fails to build for ia64: mm/mmap.c:1689:4: error: too few arguments to function ‘check_heap_stack_gap’, mm/mmap.c:1732:3: error: too few arguments to function ‘skip_heap_stack_gap’

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Dennis Schridde 2013-01-26 22:52:41 UTC]

Created attachment 336942 [details]
hardened-sources-3.2.37-r1.config

/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c: In function ‘arch_get_unmapped_area_topdown’:
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1689:4: error: too few arguments to function ‘check_heap_stack_gap’
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1521:6: note: declared here
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1706:3: error: too few arguments to function ‘check_heap_stack_gap’
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1521:6: note: declared here
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1723:3: error: too few arguments to function ‘check_heap_stack_gap’
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1521:6: note: declared here
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1732:3: error: too few arguments to function ‘skip_heap_stack_gap’
/usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1550:15: note: declared here

---

In addition, I also get:
/usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:138:30: error: all_cpu_cache_info causes a section type conflict

I assume the issue is between:
/usr/src/linux-3.2.37-hardened-r1/include/linux/init.h:#define __cpuinitdata    __section(.cpuinit.data)
and:
/usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:static struct cpu_cache_info      all_cpu_cache_info[NR_CPUS] __cpuinitdata;

Presumably the variable cannot be both in the .cpuinit.data and the static section that exists on ia64?

Removing the "static" keyword from definition fixes this error. But the next one follows right away:
/usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:447:44: error: cache_cpu_notifier causes a section type conflict


Used compiler is GCC 4.5.4, because 4.6 is broken on ia64 in that it does not create bootable kernels. (bug #447754)

[Comment 1 Dennis Schridde 2013-01-26 22:58:19 UTC]

(In reply to comment #0)
> Removing the "static" keyword from definition fixes this error. But the next
> one follows right away:
> /usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:447:44: error:
> cache_cpu_notifier causes a section type conflict
The cause of the section type conflict seems to be different than what I assumed. After making the cache_cpu_notifier non-static, I get the old error for all_cpu_cache_info again:
/usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:138:23: error: all_cpu_cache_info causes a section type conflict

[Comment 2 PaX Team 2013-01-28 13:55:00 UTC]

(In reply to comment #0)
> Created attachment 336942 [details]
> hardened-sources-3.2.37-r1.config
> 
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c: In function
> ‘arch_get_unmapped_area_topdown’:
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1689:4: error: too few arguments
> to function ‘check_heap_stack_gap’

these are due to a change in grsec, no PaX, spender's call ;).

> In addition, I also get:
> /usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:138:30: error:
> all_cpu_cache_info causes a section type conflict
> 
> I assume the issue is between:
> /usr/src/linux-3.2.37-hardened-r1/include/linux/init.h:#define __cpuinitdata
> __section(.cpuinit.data)
> and:
> /usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:static struct
> cpu_cache_info      all_cpu_cache_info[NR_CPUS] __cpuinitdata;
> 
> Presumably the variable cannot be both in the .cpuinit.data and the static
> section that exists on ia64?

the problem is cache_cpu_notifier having an explicit section flag which then conflicts with constification, just remove that (which is what i'll do in the next patch, if there's more of these, let me know).

[Comment 3 Dennis Schridde 2013-01-28 14:27:04 UTC]

(In reply to comment #2)
> > In addition, I also get:
> > /usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:138:30: error:
> > all_cpu_cache_info causes a section type conflict
> 
> the problem is cache_cpu_notifier having an explicit section flag which then
> conflicts with constification, just remove that (which is what i'll do in
> the next patch, if there's more of these, let me know).

I cannot find any "const" keyword or the like for this variable. What is it exactly that you want me to remove? __cpuinitdata? Ain't that needed for anything?

[Comment 4 PaX Team 2013-01-28 16:38:44 UTC]

(In reply to comment #3)
> > the problem is cache_cpu_notifier having an explicit section flag which then
> > conflicts with constification, just remove that (which is what i'll do in
> > the next patch, if there's more of these, let me know).
> 
> I cannot find any "const" keyword or the like for this variable.

it's the result of the constify plugin which i assume you enabled in your config ;).

> What is it exactly that you want me to remove? __cpuinitdata?

yes that one.

> Ain't that needed for anything?

it matters for cpu hotplugging at most so that on !HOTPLUG_CPU systems this data can be freed after boot.

[Comment 5 Dennis Schridde 2013-01-28 17:04:50 UTC]

(In reply to comment #4)
> (In reply to comment #3)
> > I cannot find any "const" keyword or the like for this variable.
> it's the result of the constify plugin which i assume you enabled in your
> config ;).
> > What is it exactly that you want me to remove? __cpuinitdata?
> yes that one.
Ah, I assumed the variable being const was the actual issue and stuff in the .cpuinit.data section is supposed to be modifyable.

Does that mean that the constify plugin forces every statically allocated struct to be in a special "const" section?

topology.c compiles fine after removing both instances of __cpuinitdata. So only the mm/mmap.c failure remains.

[Comment 6 PaX Team 2013-01-28 18:05:39 UTC]

(In reply to comment #5)
> Ah, I assumed the variable being const was the actual issue and stuff in the
> .cpuinit.data section is supposed to be modifyable.
> 
> Does that mean that the constify plugin forces every statically allocated
> struct to be in a special "const" section?

no, read the config help about what it does ;).

> topology.c compiles fine after removing both instances of __cpuinitdata.

all_cpu_cache_info can stay in __cpuinitdata, it's not subject to constification.

[Comment 7 Dennis Schridde 2013-01-28 19:07:56 UTC]

(In reply to comment #6)
> (In reply to comment #5)
> > Ah, I assumed the variable being const was the actual issue and stuff in the
> > .cpuinit.data section is supposed to be modifyable.
> > 
> > Does that mean that the constify plugin forces every statically allocated
> > struct to be in a special "const" section?
> 
> no, read the config help about what it does ;).
I assume you mean an entry shown by "make menuconfig"? I cannot find it there. The makefile reads:
ifndef DISABLE_PAX_CONSTIFY_PLUGIN
ifndef CONFIG_UML
CONSTIFY_PLUGIN_CFLAGS := -fplugin=$(objtree)/tools/gcc/constify_plugin.so -DCONSTIFY_PLUGIN
endif
endif

So no CONFIG_PAX_... value involved... I do not see DISABLE_PAX_... being defined under condition of some CONFIG_... value either. So I do not know what to look for in "make menuconfig".

[Comment 8 Dennis Schridde 2013-01-28 19:11:28 UTC]

(In reply to comment #0)
> /usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:138:30: error:
> all_cpu_cache_info causes a section type conflict
This error vanished, after I solved the following error by removing __cpuinitdata there:
> /usr/src/linux-3.2.37-hardened-r1/arch/ia64/kernel/topology.c:447:44: error:
> cache_cpu_notifier causes a section type conflict
No idea what the relation between the two is...

[Comment 9 PaX Team 2013-01-28 20:01:53 UTC]

(In reply to comment #7)
> I assume you mean an entry shown by "make menuconfig"? I cannot find it
> there.

yeah, in the meantime spender reminded me that he enables the constify plugin unconditionally in grsec and removed the associated config option and help, so you'll have to read up on it in PaX itself ;).

[Comment 10 Dennis Schridde 2013-02-03 16:35:26 UTC]

All issues persist in sys-kernel/hardened-sources-3.2.37-r2.

[Comment 11 Dennis Schridde 2013-02-04 19:09:57 UTC]

(In reply to comment #0)
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c: In function
> ‘arch_get_unmapped_area_topdown’:
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1689:4: error: too few arguments
> to function ‘check_heap_stack_gap’
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1521:6: note: declared here
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1706:3: error: too few arguments
> to function ‘check_heap_stack_gap’
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1521:6: note: declared here
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1723:3: error: too few arguments
> to function ‘check_heap_stack_gap’
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1521:6: note: declared here
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1732:3: error: too few arguments
> to function ‘skip_heap_stack_gap’
> /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1550:15: note: declared here
This issue also exists in 3.7.5.

---

There I also get another error:
/usr/src/linux-3.7.5-hardened/kernel/sched/core.c:6710:1: error: update_runtime_nb causes a section type conflict

The line is:
    hotcpu_notifier(update_runtime, 0);
Which expands this macro:
#define hotcpu_notifier(fn, pri)    cpu_notifier(fn, pri)
Which is then expanded to:
#define cpu_notifier(fn, pri) {                 \
    static struct notifier_block fn##_nb __cpuinitdata =    \
        { .notifier_call = fn, .priority = pri };   \
    register_cpu_notifier(&fn##_nb);            \
}

So we have the __cpuinitdata/static/const issue again...

[Comment 12 PaX Team 2013-02-11 01:41:41 UTC]

(In reply to comment #11)
> (In reply to comment #0)
> > /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c: In function
> > ‘arch_get_unmapped_area_topdown’:
> > /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1689:4: error: too few arguments
> > to function ‘check_heap_stack_gap’

this should be fixed in grsec now.

> There I also get another error:
> /usr/src/linux-3.7.5-hardened/kernel/sched/core.c:6710:1: error:
> update_runtime_nb causes a section type conflict

interesting, i have CONFIG_HOTPLUG_CPU enabled as well but don't get this error...

> #define cpu_notifier(fn, pri) {                 \
>     static struct notifier_block fn##_nb __cpuinitdata =    \
>         { .notifier_call = fn, .priority = pri };   \
>     register_cpu_notifier(&fn##_nb);            \
> }
> 
> So we have the __cpuinitdata/static/const issue again...

what happens if you change this to __cpuinitconst? and if that still fails, you can just remove it i guess. in the future i'll probably handle this from the constify plugin itself.

[Comment 13 Dennis Schridde 2013-02-11 10:11:51 UTC]

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #0)
> > > /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c: In function
> > > ‘arch_get_unmapped_area_topdown’:
> > > /usr/src/linux-3.2.37-hardened-r1/mm/mmap.c:1689:4: error: too few arguments
> > > to function ‘check_heap_stack_gap’
> 
> this should be fixed in grsec now.
Thanks!

> > There I also get another error:
> > /usr/src/linux-3.7.5-hardened/kernel/sched/core.c:6710:1: error:
> > update_runtime_nb causes a section type conflict
> 
> interesting, i have CONFIG_HOTPLUG_CPU enabled as well but don't get this
> error...
Maybe it is ia64 specific...

> what happens if you change this to __cpuinitconst? and if that still fails,
> you can just remove it i guess. in the future i'll probably handle this from
> the constify plugin itself.
I will test that once a release with a fix for the other bug is released.

[Comment 14 Dennis Schridde 2013-02-12 21:34:17 UTC]

(In reply to comment #12)
> (In reply to comment #11)
> > #define cpu_notifier(fn, pri) {                 \
> >     static struct notifier_block fn##_nb __cpuinitdata =    \
> >         { .notifier_call = fn, .priority = pri };   \
> >     register_cpu_notifier(&fn##_nb);            \
> > }
> > 
> > So we have the __cpuinitdata/static/const issue again...
> 
> what happens if you change this to __cpuinitconst? and if that still fails,
> you can just remove it i guess. in the future i'll probably handle this from
> the constify plugin itself.

I am now on 3.7.6 and have in source/include/linux/cpu.h:118:
    static struct notifier_block fn##_nb __cpuinitconst =   \

And still:
/usr/src/linux-3.7.6-hardened/kernel/sched/core.c:6710:1: error: update_runtime_nb causes a section type conflict

[Comment 15 Dennis Schridde 2013-02-18 22:17:20 UTC]

(In reply to comment #14)
> I am now on 3.7.6 and have in source/include/linux/cpu.h:118:
>     static struct notifier_block fn##_nb __cpuinitconst =   \
> 
> And still:
> /usr/src/linux-3.7.6-hardened/kernel/sched/core.c:6710:1: error:
> update_runtime_nb causes a section type conflict
This persists in 3.7.8. I removed __cpuinit* entirely now.

[Comment 16 PaX Team 2013-02-19 23:52:53 UTC]

(In reply to comment #15)
> > And still:
> > /usr/src/linux-3.7.6-hardened/kernel/sched/core.c:6710:1: error:
> > update_runtime_nb causes a section type conflict
> This persists in 3.7.8. I removed __cpuinit* entirely now.

what about gcc 4.7?

[Comment 17 Dennis Schridde 2013-02-20 08:53:45 UTC]

(In reply to comment #16)
> (In reply to comment #15)
> > > And still:
> > > /usr/src/linux-3.7.6-hardened/kernel/sched/core.c:6710:1: error:
> > > update_runtime_nb causes a section type conflict
> > This persists in 3.7.8. I removed __cpuinit* entirely now.
> 
> what about gcc 4.7?

Since GCC 4.6.3 cannot compile a bootable kernel (bug #447754), I didn't try with newer versions. (I am currently using GCC 4.5.4, which works.)

If you are sure that it will make a difference, I can build a GCC 4.7.2 and try with that. Maybe I will even try booting the resulting image, but that will have to wait a few days, since the recent move from OpenVZ to LXC already required quite some work and there is still fallout.

[Comment 18 PaX Team 2013-02-20 12:21:28 UTC]

(In reply to comment #17)
> If you are sure that it will make a difference, I can build a GCC 4.7.2 and
> try with that.

i don't know if gcc fixes this seemingly arch-specific problem, but it at least may give a better error message (in particular, the conflicting section name). also check out 3.8 that i released recently, just for another data point.

[Comment 19 Dennis Schridde 2013-02-20 19:13:15 UTC]

(In reply to comment #16)
> what about gcc 4.7?

# make CC=gcc-4.7.2
  HOSTCXX -fPIC tools/gcc/colorize_plugin.o
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:31:2: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:32:2: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:107:2: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:108:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:109:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:113:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:114:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:115:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:116:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:117:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:118:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:119:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:120:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:121:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:122:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:123:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:124:2: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default]
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’:
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:136:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:137:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:138:3: error: expected primary-expression before ‘.’ token
/usr/src/linux-3.2.38-hardened-r1/tools/gcc/colorize_plugin.c:139:3: error: expected primary-expression before ‘.’ token
make[3]: *** [tools/gcc/colorize_plugin.o] Error 1

[Comment 20 PaX Team 2013-02-20 19:26:54 UTC]

(In reply to comment #19)
> (In reply to comment #16)
> > what about gcc 4.7?
> 
> # make CC=gcc-4.7.2

specify CXX as well perhaps (this gcc can be built with both a c and a c++ compiler).

[Comment 21 Dennis Schridde 2013-02-20 20:02:52 UTC]

(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #16)
> > > what about gcc 4.7?
> > 
> > # make CC=gcc-4.7.2
> 
> specify CXX as well perhaps (this gcc can be built with both a c and a c++
> compiler).

Why do you build the plugin with a C compiler when CC=gcc-4.5.4, but with a C++ compiler when CC=gcc-4.7.2?

Anyway:
# make CC=gcc-4.7.2 HOSTCXX=g++-4.7.2
[...]
  CC      arch/ia64/kernel/topology.o
/usr/src/linux-3.2.38-hardened-r1/arch/ia64/kernel/topology.c:138:30: error: all_cpu_cache_info causes a section type conflict with cache_cpu_notifier
/usr/src/linux-3.2.38-hardened-r1/arch/ia64/kernel/topology.c:447:44: note: ‘cache_cpu_notifier’ was declared here

[Comment 22 PaX Team 2013-02-20 20:38:39 UTC]

(In reply to comment #21)
> (In reply to comment #20)
> > specify CXX as well perhaps (this gcc can be built with both a c and a c++
> > compiler).
> 
> Why do you build the plugin with a C compiler when CC=gcc-4.5.4, but with a
> C++ compiler when CC=gcc-4.7.2?

like i said above, gcc 4.7 can be built with either a c or c++ compiler,
so the plugins have to be built with the same kind of compiler (this is
what scripts/gcc-plugin.sh discovers). older compilers are c only, newer
ones (i.e., 4.8+) c++ only.

> Anyway:
> # make CC=gcc-4.7.2 HOSTCXX=g++-4.7.2
> [...]
>   CC      arch/ia64/kernel/topology.o
> /usr/src/linux-3.2.38-hardened-r1/arch/ia64/kernel/topology.c:138:30: error:
> all_cpu_cache_info causes a section type conflict with cache_cpu_notifier
> /usr/src/linux-3.2.38-hardened-r1/arch/ia64/kernel/topology.c:447:44: note:
> ‘cache_cpu_notifier’ was declared here

what was the code around those lines this time? __cpuinitdata on all_cpu_cache_info
and nothing on cache_cpu_notifier?

[Comment 23 Dennis Schridde 2013-02-20 21:58:05 UTC]

(In reply to comment #22)
> > # make CC=gcc-4.7.2 HOSTCXX=g++-4.7.2
> > [...]
> >   CC      arch/ia64/kernel/topology.o
> > /usr/src/linux-3.2.38-hardened-r1/arch/ia64/kernel/topology.c:138:30: error:
> > all_cpu_cache_info causes a section type conflict with cache_cpu_notifier
> > /usr/src/linux-3.2.38-hardened-r1/arch/ia64/kernel/topology.c:447:44: note:
> > ‘cache_cpu_notifier’ was declared here
> 
> what was the code around those lines this time? __cpuinitdata on
> all_cpu_cache_info
> and nothing on cache_cpu_notifier?

It is the stock sys-kernel/hardened-source-3.2.38-r1.

line 138:
static struct cpu_cache_info    all_cpu_cache_info[NR_CPUS] __cpuinitdata;

line 447:
static struct notifier_block __cpuinitdata cache_cpu_notifier =

[Comment 24 PaX Team 2013-02-20 22:15:25 UTC]

(In reply to comment #23)
> line 447:
> static struct notifier_block __cpuinitdata cache_cpu_notifier =

oh, i thought you'd removed this one already. i did that in the latest PaX patch already as well.

[Comment 25 Dennis Schridde 2013-02-20 22:43:03 UTC]

(In reply to comment #24)
> (In reply to comment #23)
> > line 447:
> > static struct notifier_block __cpuinitdata cache_cpu_notifier =
> 
> oh, i thought you'd removed this one already. i did that in the latest PaX
> patch already as well.

Making that one __cpuinitconst works as well. (i.e. it compiles - no idea whether it will run later)

[Comment 26 Dennis Schridde 2013-02-20 23:43:02 UTC]

(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > line 447:
> > > static struct notifier_block __cpuinitdata cache_cpu_notifier =
> > 
> > oh, i thought you'd removed this one already. i did that in the latest PaX
> > patch already as well.
> 
> Making that one __cpuinitconst works as well.

It does not boot. Maybe bug #447754 and I shall retry with gcc-4.5.4? Or is the __cpuinitconst to blame?

[Comment 27 PaX Team 2013-02-21 00:18:59 UTC]

(In reply to comment #26)
> It does not boot. Maybe bug #447754 and I shall retry with gcc-4.5.4? Or is
> the __cpuinitconst to blame?

well, you said that the same change didn't compile with gcc 4.5, so that won't help. did you try a vanilla kernel as i asked in that other bug? ;)

[Comment 28 Dennis Schridde 2013-02-21 00:48:06 UTC]

(In reply to comment #27)
> well, you said that the same change didn't compile with gcc 4.5, so that
> won't help.

Oh, sorry if I confused you. I was trying multiple kernels concurrently, all of which exposed similar problems during compilation:
* In 3.2.38-r1, making cache_cpu_notifier from arch/ia64/kernel/topology.c __cpuinitconst works - with GCC 4.5.4 and 4.7.2 (just that it does not boot with the latter - I did not try with the former, yet).
* In 3.7.5, making the cpu_notifier macro from kernel/sched/core.c produce a __cpuinitconst struct did not compile (using 4.5.4 - I did not try with 4.7.2, yet).

> did you try a vanilla kernel as i asked in that other bug? ;)

Not yet, but I am currently installing the sources on a spare machine, so I can test more freely.

[Comment 29 Dennis Schridde 2013-02-21 02:09:43 UTC]

(In reply to comment #28)
> * In 3.2.38-r1, making cache_cpu_notifier from arch/ia64/kernel/topology.c
> __cpuinitconst works - with GCC 4.5.4 and 4.7.2 (just that it does not boot
> with the latter - I did not try with the former, yet).

3.2.38-hardened-r1 with this __cpuinitconst change *boots*, when compiled with gcc-4.5.4.

[Comment 30 PaX Team 2013-02-21 02:26:58 UTC]

all right, now it's clearer, i was indeed confused as to what combination worked/failed in what ways ;). so the things to try at this point:

1. hardened (or just PaX alone) 3.7 (even better, 3.8 as i've moved since ;) with gcc 4.5 and with __cpuinitdata removed (instead of turned into __cpuinitconst). if you try the latest PaX, i did this change already there.

2. vanilla 3.7/3.8 with gcc 4.5.

3. hardened 3.2 with gcc 4.5 and with __cpuinitdata removed (as it is in PaX now).

[Comment 31 Dennis Schridde 2013-02-21 16:04:39 UTC]

(In reply to comment #30)
> 1. hardened (or just PaX alone) 3.7 (even better, 3.8 as i've moved since ;)
> with gcc 4.5 and with __cpuinitdata removed (instead of turned into
> __cpuinitconst). if you try the latest PaX, i did this change already there.
I tested hardened-sources-3.7.9 and it built with gcc-4.7.2 without any problems and modifications on my side. I will rebuild it with gcc-4.5.4 now. There is no hardened-sources-3.8.0, yet. I will try 3.8.1 once it is released, due to the ACPI bug mentioned below.

> 2. vanilla 3.7/3.8 with gcc 4.5.
vanilla-3.7.8 works without issues. That is what my LXC machine currently runs, until I find that the hardened issues are fixed. I did not try 3.7.9 with gcc-4.5.4, yet, but I assume it will also run, just as 3.7.8 does. 3.8.0 does not compile due to some ACPI bug [1], where x86 code crept into the generic parts.

> 3. hardened 3.2 with gcc 4.5 and with __cpuinitdata removed (as it is in PaX
> now).
I currently use 3.2.38-r1 with __cpuinitdata replaced by __cpuinitconst in one occastion (topology.c:447), and it runs without problems. I will test your variant once a new Gentoo package comes with that change, as currently everything works.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=54091

[Comment 32 Dennis Schridde 2013-02-21 16:41:52 UTC]

(In reply to comment #31)
> (In reply to comment #30)
> > 1. hardened (or just PaX alone) 3.7 (even better, 3.8 as i've moved since ;)
> > with gcc 4.5 and with __cpuinitdata removed (instead of turned into
> > __cpuinitconst). if you try the latest PaX, i did this change already there.
> I tested hardened-sources-3.7.9 and it built with gcc-4.7.2 without any
> problems and modifications on my side.

Ok, that was with gcc-4.7.2 only. With 4.5.4 I am back at:
/usr/src/linux-3.7.9-hardened/kernel/sched/core.c:6710:1: error: update_runtime_nb causes a section type conflict

[Comment 33 Dennis Schridde 2013-02-25 15:50:18 UTC]

(In reply to comment #32)
> (In reply to comment #31)
> > (In reply to comment #30)
> > > 1. hardened (or just PaX alone) 3.7 (even better, 3.8 as i've moved since ;)
> > > with gcc 4.5 and with __cpuinitdata removed (instead of turned into
> > > __cpuinitconst). if you try the latest PaX, i did this change already there.
> > I tested hardened-sources-3.7.9 and it built with gcc-4.7.2 without any
> > problems and modifications on my side.
> 
> Ok, that was with gcc-4.7.2 only. With 4.5.4 I am back at:
> /usr/src/linux-3.7.9-hardened/kernel/sched/core.c:6710:1: error:
> update_runtime_nb causes a section type conflict

Even with __cpuinitdata replaced by __cpuinitconst on source/include/linux/cpu.h:118 it fails to compile with the same error. Is there any way to further debug what GCC is doing there?

[Comment 34 Dennis Schridde 2013-02-27 16:26:04 UTC]

sys-kernel/hardened-sources-3.2.39 compiled and booted without further (related) trouble.

3.7.9 and 3.8.0 still need __cpuinitdata removed from source/include/linux/cpu.h:118.

[Comment 35 PaX Team 2013-03-11 02:07:32 UTC]

is there still a problem with the latest 3.8.2 patch?

[Comment 36 Tom Wijsman (TomWij) (RETIRED) 2013-04-25 13:58:07 UTC]

Reminder: Please try a more recent kernel from the 3.8 branch.

[Comment 37 Anthony Basile 2013-06-24 21:25:39 UTC]

Dennis, is this still an issue?

[Comment 38 Dennis Schridde 2013-06-25 14:06:29 UTC]

(In reply to Anthony Basile from comment #37)
> Dennis, is this still an issue?

No, I was just able to compile 3.2.46-hardened-r1 without any user patches or problems.