From: Ingo Molnar <mingo@elte.hu>
To: Rakib Mullick <rakib.mullick@gmail.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] kernel/cpu.c: Section mismatch warning fix.
Date: Mon, 3 Nov 2008 11:15:21 +0100 [thread overview]
Message-ID: <20081103101521.GH13671@elte.hu> (raw)
In-Reply-To: <b9df5fa10811011859s48e2f8dnb80d4a76001e8e67@mail.gmail.com>
* Rakib Mullick <rakib.mullick@gmail.com> wrote:
> On 10/31/08, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Rakib Mullick <rakib.mullick@gmail.com> wrote:
> >
> >
> > you've tested that on x86, right? Have you checked/reviewed all the
> > non-x86 architecture codepaths:
> >
> > ./arch/m32r/kernel/smpboot.c: notify_cpu_starting(cpu_id);
> > ./arch/cris/arch-v32/kernel/smp.c: notify_cpu_starting(cpu);
> > ./arch/s390/kernel/smp.c: notify_cpu_starting(smp_processor_id());
> > ./arch/x86/mach-voyager/voyager_smp.c: notify_cpu_starting(cpuid);
> > ./arch/x86/kernel/smpboot.c: notify_cpu_starting(cpuid);
> > ./arch/mips/kernel/smp.c: notify_cpu_starting(cpu);
> > ./arch/sparc64/kernel/smp.c: notify_cpu_starting(cpuid);
> > ./arch/ia64/kernel/smpboot.c: notify_cpu_starting(cpuid);
> > ./arch/um/kernel/smp.c: notify_cpu_starting(cpu);
> > ./arch/sparc/kernel/sun4d_smp.c: notify_cpu_starting(cpuid);
> > ./arch/sparc/kernel/sun4m_smp.c: notify_cpu_starting(cpuid);
> > ./arch/powerpc/kernel/smp.c: notify_cpu_starting(cpu);
> > ./arch/alpha/kernel/smp.c: notify_cpu_starting(cpuid);
> > ./arch/sh/kernel/smp.c: notify_cpu_starting(smp_processor_id());
> > ./arch/arm/kernel/smp.c: notify_cpu_starting(cpu);
> >
> > to make sure that they never use this function after free_initmem()?
>
> Above codepaths are basically called during initialization, where
> all the CPU's are initiated. When we complete the initial bootup
> then free_initmem is called. So, If i'm not wrong they're not using
> this function after free_initmem().And notify_cpu_started(cpuid) is
> declared when CPU_HOTPLUG is not set. So, It's safe also from CPU
> hotpluging POV. Am I missing anything?
no, you are right - applied your patch to tip/core/urgent (see the
full commit below). Just wanted to raise the question because your
changelog did not include an analysis of the situation.
Ingo
--------------------------->
>From 685aebb5fb26126e9be708cfed30e5ee20033c95 Mon Sep 17 00:00:00 2001
From: Rakib Mullick <rakib.mullick@gmail.com>
Date: Thu, 30 Oct 2008 10:04:54 +0600
Subject: [PATCH] kernel/cpu.c: section mismatch warning fix
Impact: small kernel .text reduction in certain configs, and fix warning
This warning:
LD kernel/built-in.o
WARNING: kernel/built-in.o(.text+0xb7c8): Section mismatch in
reference from the function notify_cpu_starting() to the variable
.cpuinit.data:cpu_chain
The function notify_cpu_starting() references
the variable __cpuinitdata cpu_chain.
This is often because notify_cpu_starting lacks a __cpuinitdata
annotation or the annotation of cpu_chain is wrong.
Points out the fact that notify_cpu_starting() is only called
from __cpuinit sequences and itself uses a __cpuinitdata structure.
This patch fixes the above section mismatch warning.
Signed-off-by: Md.Rakib H. Mullick <rakib.mullick@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/cpu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 86d4904..2e53420 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -462,7 +462,7 @@ out:
* It must be called by the arch code on the new cpu, before the new cpu
* enables interrupts and before the "boot" cpu returns from __cpu_up().
*/
-void notify_cpu_starting(unsigned int cpu)
+void __cpuinit notify_cpu_starting(unsigned int cpu)
{
unsigned long val = CPU_STARTING;
next prev parent reply other threads:[~2008-11-03 10:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-30 4:04 [PATCH] kernel/cpu.c: Section mismatch warning fix Rakib Mullick
2008-10-30 18:26 ` Ingo Molnar
2008-11-02 1:59 ` Rakib Mullick
2008-11-03 10:15 ` Ingo Molnar [this message]
2008-11-03 23:34 ` Andrew Morton
2008-11-04 9:48 ` Ingo Molnar
2008-11-04 10:09 ` Sam Ravnborg
2008-11-04 10:09 ` Sam Ravnborg
2008-11-04 10:22 ` Ingo Molnar
2008-11-04 10:22 ` Ingo Molnar
2008-11-04 11:02 ` Sam Ravnborg
2008-11-04 11:02 ` Sam Ravnborg
2008-11-04 13:06 ` James Bottomley
2008-11-04 13:22 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081103101521.GH13671@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rakib.mullick@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.