All of lore.kernel.org
 help / color / mirror / Atom feed
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;
 

  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.