From: Sam Ravnborg <sam@ravnborg.org>
To: Jan Beulich <jbeulich@novell.com>
Cc: Satyam Sharma <satyam.sharma@gmail.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, patches@x86-64.org
Subject: Re: [PATCH] x86: fix improper .init-type section references
Date: Tue, 12 Jun 2007 19:56:06 +0200 [thread overview]
Message-ID: <20070612175606.GB15329@uranus.ravnborg.org> (raw)
In-Reply-To: <466EB12B.76E4.0078.0@novell.com>
On Tue, Jun 12, 2007 at 02:43:55PM +0200, Jan Beulich wrote:
> >> The cacheinfo_cpu_notifier itself is called out from _cpu_down() which
> >> is ... yep, *not* __cpuinit (and obviously *cannot* be so). _cpu_down()
> >> is called from cpu_down() which is (thankfully!) protected inside
> >> #ifdef CONFIG_HOTPLUG_CPU, so we've /just about/ escaped trouble
> >> so far, but another of it's callers is disable_nonboot_cpus() which does
> >> *not* depend on HOTPLUG_CPU, but is #ifdef'ed inside SUSPEND_SMP
> >> (gargh!) instead, and ... is _not_ __cpuinit either (obviously, again).
> >
> >Wait, SUSPEND_SMP again depends on HOTPLUG_CPU, so there
> >are no issues here in marking cache_remove_dev() __cpuexit
> >(which effectively simply becomes #ifdef HOTPLUG_CPU) as all
> >callsites that call out the notifier with CPU_DEAD/FROZEN are also
> >going to be disabled. [ Ok, looks like using __cpuexit as this kind of
> >pseudo-#ifdef HOTPLUG_CPU is a standard practice? ]
> >
> >But modpost will still complain (bogus warning) about calling __exit
> >from __init (when HOTPLUG_CPU=n) for cacheinfo_cpu_callback()
> >calling cache_remove_dev(), no?
>
> No, it doesn't, at least not for me. And from a purely theoretical
> perspective I don't think such references should be considered bad -
> .exit.* should be discarded together with .init.* if unloading is
> impossible (built-in or configured off), not before module/kernel
> initialization. This is specifically because init code may want to utilize
> exit code in case of initialization failure.
For the builtin case some arch's drop exit code during link time
so using function marked __exit from __init will cause a
linker bug. For i386 __exit is discarded at runtime - but dunno when in the
init sequence.
Sam
prev parent reply other threads:[~2007-06-12 17:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-12 7:48 Jan Beulich
2007-06-12 11:14 ` Satyam Sharma
2007-06-12 12:09 ` Satyam Sharma
2007-06-12 12:43 ` Jan Beulich
2007-06-12 13:32 ` Satyam Sharma
2007-06-12 13:49 ` Jan Beulich
2007-06-12 14:09 ` Satyam Sharma
2007-06-12 18:00 ` Sam Ravnborg
2007-06-13 3:18 ` Satyam Sharma
2007-06-13 4:35 ` Sam Ravnborg
2007-06-13 6:59 ` Jan Beulich
2007-06-13 7:39 ` Satyam Sharma
2007-06-13 7:49 ` Jan Beulich
2007-06-13 8:10 ` Sam Ravnborg
2007-06-12 17:56 ` Sam Ravnborg [this message]
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=20070612175606.GB15329@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=ak@suse.de \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@x86-64.org \
--cc=satyam.sharma@gmail.com \
--cc=venkatesh.pallipadi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®