All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: mm: memory/cpu hotplug section mismatch.
Date: Tue, 12 Jun 2007 00:44:28 +0900	[thread overview]
Message-ID: <20070611154428.GA27644@linux-sh.org> (raw)
In-Reply-To: <20070611082732.70018522.randy.dunlap@oracle.com>

On Mon, Jun 11, 2007 at 08:27:32AM -0700, Randy Dunlap wrote:
> On Mon, 11 Jun 2007 14:09:55 +0900 Paul Mundt wrote:
> > On Mon, Jun 11, 2007 at 02:01:45PM +0900, KAMEZAWA Hiroyuki wrote:
> > > On Mon, 11 Jun 2007 13:35:43 +0900
> > > Paul Mundt <lethal@linux-sh.org> wrote:
> > > > This happens because CONFIG_HOTPLUG_CPU=n sets __cpuinit to __init, but
> > > > CONFIG_MEMORY_HOTPLUG=y unsets __meminit.
> > > 
> > > It seems this zone_batchsize() is called by cpu-hotplug and
> > > memory-hotplug.  So, __init_refok doesn't look good, here.
> > > 
> > > maybe we can use __devinit here. (Because HOTPLUG_CPU and
> > > MEMORY_HOTPLUG are depend on CONFIG_HOTPLUG.)
> > > 
> > Yes, that's probably a more reasonable way to go. The __devinit name is a
> > bit misleading, though..
> 
> __meminit does not fit/work here?
> 
No, for the reasons already noted.

If CONFIG_MEMORY_HOTPLUG=n __meminit == __init, and if
CONFIG_HOTPLUG_CPU=n __cpuinit == __init. However, with one set and the
other disabled, you end up with a reference between __init and a regular
non-init function.

CONFIG_HOTPLUG is the only thing that they both have in common, so only
__devinit will gaurantee the proper behaviour. __init_refok is the
opposite of the behaviour that is desired, as Kamezawa-san was quick to
point out.

Simply switching to __meminit will cause zone_batchlist() to emit a
section mismatch on CONFIG_HOTPLUG_CPU=y and CONFIG_MEMORY_HOTPLUG=n
configurations instead of the other way around.

WARNING: multiple messages have this Message-ID (diff)
From: Paul Mundt <lethal@linux-sh.org>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: mm: memory/cpu hotplug section mismatch.
Date: Tue, 12 Jun 2007 00:44:28 +0900	[thread overview]
Message-ID: <20070611154428.GA27644@linux-sh.org> (raw)
In-Reply-To: <20070611082732.70018522.randy.dunlap@oracle.com>

On Mon, Jun 11, 2007 at 08:27:32AM -0700, Randy Dunlap wrote:
> On Mon, 11 Jun 2007 14:09:55 +0900 Paul Mundt wrote:
> > On Mon, Jun 11, 2007 at 02:01:45PM +0900, KAMEZAWA Hiroyuki wrote:
> > > On Mon, 11 Jun 2007 13:35:43 +0900
> > > Paul Mundt <lethal@linux-sh.org> wrote:
> > > > This happens because CONFIG_HOTPLUG_CPU=n sets __cpuinit to __init, but
> > > > CONFIG_MEMORY_HOTPLUG=y unsets __meminit.
> > > 
> > > It seems this zone_batchsize() is called by cpu-hotplug and
> > > memory-hotplug.  So, __init_refok doesn't look good, here.
> > > 
> > > maybe we can use __devinit here. (Because HOTPLUG_CPU and
> > > MEMORY_HOTPLUG are depend on CONFIG_HOTPLUG.)
> > > 
> > Yes, that's probably a more reasonable way to go. The __devinit name is a
> > bit misleading, though..
> 
> __meminit does not fit/work here?
> 
No, for the reasons already noted.

If CONFIG_MEMORY_HOTPLUG=n __meminit == __init, and if
CONFIG_HOTPLUG_CPU=n __cpuinit == __init. However, with one set and the
other disabled, you end up with a reference between __init and a regular
non-init function.

CONFIG_HOTPLUG is the only thing that they both have in common, so only
__devinit will gaurantee the proper behaviour. __init_refok is the
opposite of the behaviour that is desired, as Kamezawa-san was quick to
point out.

Simply switching to __meminit will cause zone_batchlist() to emit a
section mismatch on CONFIG_HOTPLUG_CPU=y and CONFIG_MEMORY_HOTPLUG=n
configurations instead of the other way around.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-06-11 15:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-11  4:35 mm: memory/cpu hotplug section mismatch Paul Mundt
2007-06-11  4:35 ` Paul Mundt
2007-06-11  5:01 ` KAMEZAWA Hiroyuki
2007-06-11  5:01   ` KAMEZAWA Hiroyuki
2007-06-11  5:09   ` Paul Mundt
2007-06-11  5:09     ` Paul Mundt
2007-06-11 15:27     ` Randy Dunlap
2007-06-11 15:27       ` Randy Dunlap
2007-06-11 15:44       ` Paul Mundt [this message]
2007-06-11 15:44         ` Paul Mundt
2007-06-11 18:40         ` Sam Ravnborg
2007-06-11 18:40           ` Sam Ravnborg
2007-06-12  1:50           ` Yasunori Goto
2007-06-12  1:50             ` Yasunori Goto
2007-06-12  3:19             ` Paul Mundt
2007-06-12  3:19               ` Paul Mundt

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=20070611154428.GA27644@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=randy.dunlap@oracle.com \
    --cc=sam@ravnborg.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 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.