From: "Satyam Sharma" <satyam.sharma@gmail.com>
To: "Jan Beulich" <jbeulich@novell.com>
Cc: "Andi Kleen" <ak@suse.de>,
linux-kernel@vger.kernel.org, patches@x86-64.org,
"Sam Ravnborg" <sam@ravnborg.org>,
"Venkatesh Pallipadi" <venkatesh.pallipadi@intel.com>
Subject: Re: [PATCH] x86: fix improper .init-type section references
Date: Tue, 12 Jun 2007 17:39:10 +0530 [thread overview]
Message-ID: <a781481a0706120509k89c331ela81f57ad0f0e29eb@mail.gmail.com> (raw)
In-Reply-To: <a781481a0706120414g385ccfe8j82b5b18d96d064f2@mail.gmail.com>
Hi Jan,
On 6/12/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> On 6/12/07, Jan Beulich <jbeulich@novell.com> wrote:
> > [...]
> > @@ -448,7 +448,7 @@ static void __cpuinit cache_shared_cpu_m
> > -static void __cpuinit cache_remove_shared_cpu_map(unsigned int cpu, int index)
> > +static void __cpuexit cache_remove_shared_cpu_map(unsigned int cpu, int index)
>
> You might've done this because the caller of
> cache_remove_shared_cpu_map() is cache_remove_dev()
> which is __cpuexit. However, cache_remove_dev() itself is called
> from cacheinfo_cpu_callback() which is ... __cpuinit, because it's
> caller cache_sysfs_init() is *definitely* __cpuinit. What a mess ...
>
> device_initcall(cache_sysfs_init):
>
> __cpuinit cache_sysfs_init
> -> __cpuinit cacheinfo_cpu_callback <======== PROBLEM
> -> __cpuexit cache_remove_dev <======== PROBLEM
> -> __cpuinit cache_remove_shared_cpu_map
>
> Where cacheinfo_cpu_callback() itself is the callback for the
> cacheinfo_cpu_notifier notifier, which is itself marked __cpuinitdata.
>
> I suspect the __cpuexit-marking of cache_remove_dev() here is totally
> bogus. When !CONFIG_HOTPLUG_CPU, __cpuexit == __exit, and
> __exit simply means that the function can be discarded and ignored
> from being linked in for non-modular (built-in) build of that particular
> module. I'm not sure how the code in question here can ever be built
> as a module, so cache_remove_dev shouldn't be a __cpuexit in the
> first place. But not marking it anything would take us back to the
> modpost warnings. So ... something needs to be done about the
> logic in this whole place ...
>
> I did some more code inspection and found:
>
> 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?
So I'd guess all the various notifier callback functions in your patch
need to be whitelisted by modpost, as those are __init functions
who can legally reference __exit (when HOTPLUG_CPU=n).
__init_refok can't be used here, so some special whitelisting might
be required, I presume.
Satyam
next prev parent reply other threads:[~2007-06-12 12:09 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 [this message]
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
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=a781481a0706120509k89c331ela81f57ad0f0e29eb@mail.gmail.com \
--to=satyam.sharma@gmail.com \
--cc=ak@suse.de \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@x86-64.org \
--cc=sam@ravnborg.org \
--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®