summaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorSam Ravnborg <sam@ravnborg.org>2008-02-01 17:49:41 +0100
committerIngo Molnar <mingo@elte.hu>2008-02-01 17:49:41 +0100
commit69e97c028b25ef10018d513ead6e7caad276e19f (patch)
tree307300ac0748c822be2f0c733302b89968e9cead /arch
parent32ed937d0596e849e1976791e78c006cee8356ca (diff)
downloadlinux-3.10-69e97c028b25ef10018d513ead6e7caad276e19f.tar.gz
linux-3.10-69e97c028b25ef10018d513ead6e7caad276e19f.tar.bz2
linux-3.10-69e97c028b25ef10018d513ead6e7caad276e19f.zip
x86: silence section mismatch warning in smpboot_64.c
Silence the following warning: WARNING: o-x86_64/arch/x86/kernel/built-in.o(.text+0x17cd3): Section mismatch in reference from the function remove_cpu_from_maps() to the variable .cpuinit.data:cpu_initialized remove_cpu:maps() had a single user: __cpu_disable() so mark it static and annotate it with __ref to silence the warning from modpost. _cpu_disable() has a single user in kernel/cpu.c: => take_cpu_down() which again has a single user in the following call: => __stop_machine_run(take_cpu_down, &tcd_param, cpu); Here a kthread is created. So maybe the warning is correct and the right fix is to remove the __cpuinitdata annotation of cpu_initialized? Note: The analysis were disturbed by the fact that we had a variable with the same name in cpu/common.c - but this is 32 bit only] Note: Should smpboot_64 use cpu_clear()? Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'arch')
-rw-r--r--arch/x86/kernel/smpboot_64.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/x86/kernel/smpboot_64.c b/arch/x86/kernel/smpboot_64.c
index cc64b8085c2..d53bd6fcb42 100644
--- a/arch/x86/kernel/smpboot_64.c
+++ b/arch/x86/kernel/smpboot_64.c
@@ -1019,7 +1019,7 @@ static void remove_siblinginfo(int cpu)
cpu_clear(cpu, cpu_sibling_setup_map);
}
-void remove_cpu_from_maps(void)
+static void __ref remove_cpu_from_maps(void)
{
int cpu = smp_processor_id();