Re: Section mismatch: kernel/cpu.c

From: Sam Ravnborg
Date: Mon Feb 04 2008 - 00:59:48 EST


On Mon, Feb 04, 2008 at 10:16:23AM +0800, Peter Teoh wrote:
> Compiling the latest linus tree will encounter the following warning:
>
> WARNING: kernel/built-in.o(.text+0x2f5e2): Section mismatch in
> reference from the function enable_nonboot_cpus() to the function
> .cpuinit.text:_cpu_up()
> The function enable_nonboot_cpus() references
> the function __cpuinit _cpu_up().
> This is often because enable_nonboot_cpus lacks a __cpuinit
> annotation or the annotation of _cpu_up is wrong.
>
> WARNING: kernel/built-in.o(.text+0x2f638): Section mismatch in
> reference from the function take_cpu_down() to the variable
> .cpuinit.data:cpu_chain
> The function take_cpu_down() references
> the variable __cpuinitdata cpu_chain.
> This is often because take_cpu_down lacks a __cpuinitdata
> annotation or the annotation of cpu_chain is wrong.
>
> WARNING: kernel/built-in.o(.text+0x2f6bb): Section mismatch in
> reference from the function _cpu_down() to the variable
> .cpuinit.data:cpu_chain
> The function _cpu_down() references
> the variable __cpuinitdata cpu_chain.
> This is often because _cpu_down lacks a __cpuinitdata
> annotation or the annotation of cpu_chain is wrong.
>
> WARNING: kernel/built-in.o(.text+0x2f6e1): Section mismatch in
> reference from the function _cpu_down() to the variable
> .cpuinit.data:cpu_chain
> The function _cpu_down() references
> the variable __cpuinitdata cpu_chain.
> This is often because _cpu_down lacks a __cpuinitdata
> annotation or the annotation of cpu_chain is wrong.
>
> WARNING: kernel/built-in.o(.text+0x2f762): Section mismatch in
> reference from the function _cpu_down() to the variable
> .cpuinit.data:cpu_chain
> The function _cpu_down() references
> the variable __cpuinitdata cpu_chain.
> This is often because _cpu_down lacks a __cpuinitdata
> annotation or the annotation of cpu_chain is wrong.
>
> WARNING: kernel/built-in.o(.text+0x2f7a2): Section mismatch in
> reference from the function _cpu_down() to the variable
> .cpuinit.data:cpu_chain
> The function _cpu_down() references
> the variable __cpuinitdata cpu_chain.
> This is often because _cpu_down lacks a __cpuinitdata
> annotation or the annotation of cpu_chain is wrong.
>
> WARNING: kernel/built-in.o(.text+0x2f88b): Section mismatch in
> reference from the function unregister_cpu_notifier() to the variable
> .cpuinit.data:cpu_chain
> The function unregister_cpu_notifier() references
> the variable __cpuinitdata cpu_chain.
> This is often because unregister_cpu_notifier lacks a __cpuinitdata
> annotation or the annotation of cpu_chain is wrong.
>
> WARNING: kernel/built-in.o(__ksymtab+0x7f0): Section mismatch in
> reference from the variable __ksymtab_register_cpu_notifier to the
> function .cpuinit.text:register_cpu_notifier()
> The symbol register_cpu_notifier is exported and annotated __cpuinit
> Fix this by removing the __cpuinit annotation of register_cpu_notifier
> or drop the export.
>
> It is basically a mismatch between __init and non-__init sections of
> the object module. It is also caused by casting an exported symbol
> (which have its own section called __ksymtabXXX) with __cpuinit. Not
> sure if a variable or function can reincarnate as two different
> section naming???? If not possible, then the following is the fix to
> correct all the above warning:
>
> Signed-off-by: Peter Teoh <htmldeveloper@xxxxxxxxx>
>
> --- cpu.c.orig 2008-02-04 09:36:35.000000000 +0800
> +++ cpu.c 2008-02-04 10:04:35.000000000 +0800
> @@ -18,7 +18,7 @@
> /* Serializes the updates to cpu_online_map, cpu_present_map */
> static DEFINE_MUTEX(cpu_add_remove_lock);
>
> -static __cpuinitdata RAW_NOTIFIER_HEAD(cpu_chain);
> +static RAW_NOTIFIER_HEAD(cpu_chain);


I have the same fix queued up. Patch attached.
But I have my doughts it is correct and I need to investigate
a bit more.

The rest of your changes I am not certain about and I need
to study the uses of the various *cpu* primitives from
all archs better before I judge on them.

In general kernel/cpu.c is tricky. Fixing up drivers
is many times easier.

Sam