From: Borislav Petkov <bp@amd64.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH] powernow-k8: Fix section mismatch
Date: Sat, 29 May 2010 11:31:19 +0200 [thread overview]
Message-ID: <20100529093119.GA24169@aftab> (raw)
In-Reply-To: <20100528140908.057f2348.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, May 28, 2010 at 05:09:08PM -0400
Hi Andrew,
> On Tue, 25 May 2010 17:28:58 +0200
> Borislav Petkov <borislav.petkov@amd.com> wrote:
>
> > Fix the following warning:
> >
> > "WARNING: arch/x86/kernel/built-in.o(.exit.text+0x72):
> > Section mismatch in reference from the function powernowk8_exit() to the variable .cpuinit.data:cpb_nb
> >
> > The function __exit powernowk8_exit() references a variable
> > __cpuinitdata cpb_nb. This is often seen when error handling in the exit
> > function uses functionality in the init path. The fix is often to remove
> > the __cpuinitdata annotation of cpb_nb so it may be used outside an init
> > section."
> >
> > Cc: <stable@kernel.org>
> > Reported-by: H. Peter Anvin <hpa@zytor.com>
> > Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> > ---
> > arch/x86/kernel/cpu/cpufreq/powernow-k8.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
> > index 6f3dc8f..7ec2123 100644
> > --- a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
> > +++ b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
> > @@ -1497,8 +1497,8 @@ static struct cpufreq_driver cpufreq_amd64_driver = {
> > * simply keep the boost-disable flag in sync with the current global
> > * state.
> > */
> > -static int __cpuinit cpb_notify(struct notifier_block *nb, unsigned long action,
> > - void *hcpu)
> > +static int cpb_notify(struct notifier_block *nb, unsigned long action,
> > + void *hcpu)
> > {
> > unsigned cpu = (long)hcpu;
> > u32 lo, hi;
> > @@ -1528,7 +1528,7 @@ static int __cpuinit cpb_notify(struct notifier_block *nb, unsigned long action,
> > return NOTIFY_OK;
> > }
> >
> > -static struct notifier_block __cpuinitdata cpb_nb = {
> > +static struct notifier_block cpb_nb = {
> > .notifier_call = cpb_notify,
> > };
>
> I _think_ this is notabug. If CONFIG_HOTPLUG_CPU=y, this code/data
> doesn't get discarded. If CONFIG_HOTPLUG_CPU=n,
> [un]register_cpu_notifier() is a no-op.
>
> But apparently the build system _did_ detect such a reference, so
> what's going on? Maybe I'm confused again.
No, you're right. We need all that notifier code strictly for when we
take a cpu offline. The registration should too be cpu hotplug-aware for
it is the only logical thing to do. However...
> This code needs work. It should use hotcpu_notifier() rather than
> diving down into the lower-level register_cpu_notifier(). If this is
> done then linker magic will cause all the hotplug-specific code to be
> omitted from vmlinux if CONFIG_HOTPLUG_CPU=n, and I suppose it will fix
> the above warning.
... the original warning is __exit versus __cpuinitdata section
marking which CONFIG_DEBUG_SECTION_MISMATCH complains about. Using the
[un]register_hotcpu_notifier() causes another one:
WARNING: kernel/built-in.o(.text+0x12fc5): Section mismatch in reference from the function __cpu_notify() to the variable .cpuinit.data:cpu_chain
The function __cpu_notify() references
the variable __cpuinitdata cpu_chain.
This is often because __cpu_notify lacks a __cpuinitdata
annotation or the annotation of cpu_chain is wrong.
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x3ba8d): Section mismatch in reference from the function __cpu_notify() to the variable .cpuinit.data:cpu_chain
The function __cpu_notify() references
the variable __cpuinitdata cpu_chain.
This is often because __cpu_notify lacks a __cpuinitdata
annotation or the annotation of cpu_chain is wrong.
so we're kinda like between a rock and a hard place here :).
Bottomline is: I wanna unregister the notifier at module exit time, and,
at the same time, get rid of all that code when CONFIG_HOTPLUG_CPU is
off.
But, if .cpuinit.data is being discarded at link time and the module
exit function references a .cpuinit.data symbol, we're simply dropping
all those [un]register_cpu_notifier() calls. Which means an unused
function and a notifier_block.
It could be that the above is becoming moot, though, for HOTPLUG_CPU
is almost always enabled (and being selected by a bunch of other core
stuff especially like PM_SLEEP_SMP etc) so we can save us the trouble of
section marking all those symbols. In this case of EMBEDDED you simply
disable powernow-k8.
But I don't know, I might just as well be missing something else.
Thanks.
--
Regards/Gruss,
Boris.
Operating Systems Research Center
Advanced Micro Devices, Inc.
next prev parent reply other threads:[~2010-05-29 9:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 15:28 [PATCH] powernow-k8: Fix section mismatch Borislav Petkov
2010-05-26 20:21 ` [tip:x86/urgent] x86, k8: Fix section mismatch for powernowk8_exit() tip-bot for Borislav Petkov
2010-05-28 21:09 ` [PATCH] powernow-k8: Fix section mismatch Andrew Morton
2010-05-29 9:31 ` Borislav Petkov [this message]
2010-05-29 9:48 ` Borislav Petkov
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=20100529093119.GA24169@aftab \
--to=bp@amd64.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox